diff options
author | Rémy Coutable <remy@rymai.me> | 2017-02-16 17:43:49 +0100 |
---|---|---|
committer | Rémy Coutable <remy@rymai.me> | 2017-02-16 17:57:03 +0100 |
commit | c6ab1e9d36e3791f5938078cb52f2b67ec4f977d (patch) | |
tree | 2dadc089d47121cf9e3ab134af262335f351b588 | |
parent | 2d2cdd64306a69aba852dd3ce26cb89b1c25655c (diff) | |
download | gitlab-ce-c6ab1e9d36e3791f5938078cb52f2b67ec4f977d.tar.gz |
Document better the CE -> EE mergedocument-ce-to-ee
Signed-off-by: Rémy Coutable <remy@rymai.me>
-rw-r--r-- | CONTRIBUTING.md | 18 | ||||
-rw-r--r-- | doc/development/limit_ee_conflicts.md | 25 |
2 files changed, 26 insertions, 17 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 72cd57ad7ff..de32a953f63 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -93,18 +93,20 @@ Please see the [UX Guide for GitLab]. ### Retrospective -After each release (usually on the 22nd of each month), we have a retrospective -call where we discuss what went well, what went wrong, and what we can improve -for the next release. The [retrospective notes] are public and you are invited -to comment them. -If you're interested, you can even join the [retrospective call][retro-kickoff-call]. +After each release, we have a retrospective call where we discuss what went well, +what went wrong, and what we can improve for the next release. The +[retrospective notes] are public and you are invited to comment on them. +If you're interested, you can even join the +[retrospective call][retro-kickoff-call], on the first working day after the +22nd at 6pm CET / 9am PST. ### Kickoff -Before working on the next release (usually on the 8th of each month), we have a +Before working on the next release, we have a kickoff call to explain what we expect to ship in the next release. The -[kickoff notes] are public and you are invited to comment them. -If you're interested, you can even join the [kickoff call][retro-kickoff-call]. +[kickoff notes] are public and you are invited to comment on them. +If you're interested, you can even join the [kickoff call][retro-kickoff-call], +on the first working day after the 7th at 6pm CET / 9am PST.. [retrospective notes]: https://docs.google.com/document/d/1nEkM_7Dj4bT21GJy0Ut3By76FZqCfLBmFQNVThmW2TY/edit?usp=sharing [kickoff notes]: https://docs.google.com/document/d/1ElPkZ90A8ey_iOkTvUs_ByMlwKK6NAB2VOK5835wYK0/edit?usp=sharing diff --git a/doc/development/limit_ee_conflicts.md b/doc/development/limit_ee_conflicts.md index 568dedf1669..2d82b09f301 100644 --- a/doc/development/limit_ee_conflicts.md +++ b/doc/development/limit_ee_conflicts.md @@ -2,19 +2,26 @@ This guide contains best-practices for avoiding conflicts between CE and EE. -## Context +## Daily CE Upstream merge -Usually, GitLab Community Edition is merged into the Enterprise Edition once a -week. During these merges, it's very common to get conflicts when some changes -in CE do not apply cleanly to EE. +GitLab Community Edition is merged daily into the Enterprise Edition (look for +the [`CE Upstream` merge requests]). The daily merge is currently done manually +by four individuals. -There are a few things that can help you as a developer to: +**If a developer pings you in a `CE Upstream` merge request for help with +resolving conflicts, please help them because it means that you didn't do your +job to reduce the conflicts nor to ease their resolution in the first place!** -- know when your merge request to CE will conflict when merged to EE -- avoid such conflicts in the first place -- ease future conflict resolutions if conflict is inevitable +To avoid the conflicts beforehand when working on CE, there are a few tools and +techniques that can help you: -## Check the `rake ee_compat_check` in your merge requests +- know what are the usual types of conflicts and how to prevent them +- the CI `rake ee_compat_check` job tells you if you need to open an EE-version + of your CE merge request + +[`CE Upstream` merge requests]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?label_name%5B%5D=CE+upstream + +## Check the status of the CI `rake ee_compat_check` job For each commit (except on `master`), the `rake ee_compat_check` CI job tries to detect if the current branch's changes will conflict during the CE->EE merge. |