diff options
| author | Adam Niedzielski <adamsunday@gmail.com> | 2017-02-28 11:12:48 +0000 |
|---|---|---|
| committer | Adam Niedzielski <adamsunday@gmail.com> | 2017-02-28 11:12:48 +0000 |
| commit | 2de90dabff56c56902d3bec2c6f7de3781242126 (patch) | |
| tree | c097541e60d931e38c46dcedf915525e94e7ab65 | |
| parent | cd92c84b5617970ee4b143687120668c6efa4a72 (diff) | |
| download | gitlab-ce-2de90dabff56c56902d3bec2c6f7de3781242126.tar.gz | |
Clarify when to create EE compatibility MR in code review process
| -rw-r--r-- | doc/development/limit_ee_conflicts.md | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/doc/development/limit_ee_conflicts.md b/doc/development/limit_ee_conflicts.md index 2d82b09f301..e3568b65b18 100644 --- a/doc/development/limit_ee_conflicts.md +++ b/doc/development/limit_ee_conflicts.md @@ -50,6 +50,12 @@ Notes: asking a GitLab developer to do it once the merge request is merged. - If you branch is more than 500 commits behind `master`, the job will fail and you should rebase your branch upon latest `master`. +- Code reviews for merge requests often consist of multiple iterations of + feedback and fixes. There is no need to update your EE MR after each + iteration. Instead, create an EE MR as soon as you see the + `rake ee_compat_check` job failing and update it after the CE MR is merged. + This helps to identify significant conflicts sooner, but also reduces the + number of times you have to resolve conflicts. ## Possible type of conflicts |