Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Tatuya Kamada
gitlab-ce
Commits
c6ab1e9d
Commit
c6ab1e9d
authored
Feb 16, 2017
by
Rémy Coutable
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Document better the CE -> EE merge
Signed-off-by:
Rémy Coutable
<
remy@rymai.me
>
parent
2d2cdd64
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
26 additions
and
17 deletions
+26
-17
CONTRIBUTING.md
CONTRIBUTING.md
+10
-8
doc/development/limit_ee_conflicts.md
doc/development/limit_ee_conflicts.md
+16
-9
No files found.
CONTRIBUTING.md
View file @
c6ab1e9d
...
@@ -93,18 +93,20 @@ Please see the [UX Guide for GitLab].
...
@@ -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
...
...
doc/development/limit_ee_conflicts.md
View file @
c6ab1e9d
...
@@ -2,19 +2,26 @@
...
@@ -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.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment