kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Document better the CE -> EE merge

Browse source 
Signed-off-by: Rémy Coutable <remy@rymai.me>
This commit is contained in:
Rémy Coutable 2017-02-16 17:43:49 +01:00
parent 2d2cdd6430
commit c6ab1e9d36
No known key found for this signature in database
GPG key ID: 46DF07E5CD9E96AB
2 changed files with 26 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
CONTRIBUTING.md
View file

@ -93,18 +93,20 @@ Please see the [UX Guide for GitLab].
### Retrospective ### Retrospective
After each release (usually on the 22nd of each month), we have a retrospective After each release, we have a retrospective call where we discuss what went well,
call where we discuss what went well, what went wrong, and what we can improve what went wrong, and what we can improve for the next release. The
for the next release. The [retrospective notes] are public and you are invited [retrospective notes] are public and you are invited to comment on them.
to comment them. If you're interested, you can even join the
If you're interested, you can even join the [retrospective call][retro-kickoff-call]. [retrospective call][retro-kickoff-call], on the first working day after the
22nd at 6pm CET / 9am PST.
### Kickoff ### 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 call to explain what we expect to ship in the next release. The
[kickoff notes] are public and you are invited to comment them. [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]. 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 [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 [kickoff notes]: https://docs.google.com/document/d/1ElPkZ90A8ey_iOkTvUs_ByMlwKK6NAB2VOK5835wYK0/edit?usp=sharing

25
doc/development/limit_ee_conflicts.md
View file

@ -2,19 +2,26 @@
This guide contains best-practices for avoiding conflicts between CE and EE. 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 GitLab Community Edition is merged daily into the Enterprise Edition (look for
week. During these merges, it's very common to get conflicts when some changes the [`CE Upstream` merge requests]). The daily merge is currently done manually
in CE do not apply cleanly to EE. 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 To avoid the conflicts beforehand when working on CE, there are a few tools and
- avoid such conflicts in the first place techniques that can help you:
- ease future conflict resolutions if conflict is inevitable
## 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 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. detect if the current branch's changes will conflict during the CE->EE merge.