diff options
Diffstat (limited to 'PROCESS.md')
| -rw-r--r-- | PROCESS.md | 55 |
1 files changed, 45 insertions, 10 deletions
diff --git a/PROCESS.md b/PROCESS.md index 3b97a4e8c75..e5b17784d20 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -119,6 +119,12 @@ only be left until after the freeze if: are aware of it. * It is in the correct milestone, with the ~Deliverable label. +If a merge request is not ready, but the developers and Product Manager +responsible for the feature think it is essential that it is in the release, +they can [ask for an exception](#asking-for-an-exception) in advance. This is +preferable to merging something that we are not confident in, but should still +be a rare case: most features can be allowed to slip a release. + All Community Edition merge requests from GitLab team members merged on the freeze date (the 7th) should have a corresponding Enterprise Edition merge request, even if there are no conflicts. This is to reduce the size of the @@ -128,11 +134,26 @@ information, see ### After the 7th -Once the stable branch is frozen, only fixes for regressions (bugs introduced in that same release) -and security issues will be cherry-picked into the stable branch. -Any merge requests cherry-picked into the stable branch for a previous release will also be picked into the latest stable branch. -These fixes will be shipped in the next RC for that release if it is before the 22nd. -If the fixes are are completed on or after the 22nd, they will be shipped in a patch for that release. +Once the stable branch is frozen, the only MRs that can be cherry-picked into +the stable branch are: + +* Fixes for [regressions](#regressions) +* Fixes for security issues +* New or updated translations (as long as they do not touch application code) + +Any merge requests cherry-picked into the stable branch for a previous release +will also be picked into the latest stable branch. These fixes will be shipped +in the next RC for that release if it is before the 22nd. If the fixes are are +completed on or after the 22nd, they will be shipped in a patch for that +release. + +During the feature freeze all merge requests that are meant to go into the upcoming +release should have the correct milestone assigned _and_ have the label +~"Pick into Stable" set, so that release managers can find and pick them. +Merge requests without a milestone and this label will +not be merged into any stable branches. + +### Asking for an exception If you think a merge request should go into an RC or patch even though it does not meet these requirements, you can ask for an exception to be made. Exceptions require sign-off from 3 people besides the developer: @@ -152,11 +173,25 @@ When in doubt, we err on the side of _not_ cherry-picking. For example, it is likely that an exception will be made for a trivial 1-5 line performance improvement (e.g. adding a database index or adding `includes` to a query), but not for a new feature, no matter how relatively small or thoroughly tested. -During the feature freeze all merge requests that are meant to go into the upcoming -release should have the correct milestone assigned _and_ have the label -~"Pick into Stable" set, so that release managers can find and pick them. -Merge requests without a milestone and this label will -not be merged into any stable branches. +All MRs which have had exceptions granted must be merged by the 15th. + +### Regressions + +A regression for a particular monthly release is a bug that exists in that +release, but wasn't present in the release before. This includes bugs in +features that were only added in that monthly release. Every regression **must** +have the milestone of the release it was introduced in - if a regression doesn't +have a milestone, it might be 'just' a bug! + +For instance, if 10.5.0 adds a feature, and that feature doesn't work correctly, +then this is a regression in 10.5. If 10.5.1 then fixes that, but 10.5.3 somehow +reintroduces the bug, then this bug is still a regression in 10.5. + +Because GitLab.com runs release candidates of new releases, a regression can be +reported in a release before its 'official' release date on the 22nd of the +month. When we say 'the most recent monthly release', this can refer to either +the version currently running on GitLab.com, or the most recent version +available in the package repositories. ## Release retrospective and kickoff |