Clarify when to create EE compatibility MR in code review process
/cc @smcgivern
Merge request reports
Activity
50 50 asking a GitLab developer to do it once the merge request is merged. 51 51 - If you branch is more than 500 commits behind `master`, the job will fail and 52 52 you should rebase your branch upon latest `master`. 53 - Code reviews for merge requests often consist of multiple iterations of 54 feedback and fixes. There is no need to update your EE MR after each 55 iteration. Instead, create an EE MR as soon as you see the 56 `rake ee_compat_check` job failing and update it after the CE MR is merged. Right, I prefer to have both MRs green before merging. Good point @smcgivern!
@smcgivern @rymai If EE MR has to be updated before CE MR is merged then it requires that a maintainer each time before merging a MR has to say "This is ready for merging. Please update EE MR and ping me here". Is it how we want to handle the process? If so, I can submit a MR that updates the description.
-
@adamniedzielski that is my preferred flow, yes!
@adamniedzielski Could you please submit an update? Also, I think this is worth mentioning in CONTRIBUTING.md under https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#getting-your-merge-request-reviewed-approved-and-merged
Now that we merge CE into EE daily, we cannot have a EE MR that is not ready when the CE MR is merged, otherwise we end-up with really painful conflicts. This is a good example: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1370 / https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/1370#note_25401471 / https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9688#note_25402514
-
@rymai I updated a while ago - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9681. I should've cced you.
@adamniedzielski Cool, no problem!
