From 2d8eb2dc6a10a48645253b0b3ead6b61dd9c4634 Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Wed, 8 Feb 2017 15:16:39 -0600 Subject: Describe process around cherry-picking during the feature freeze --- PROCESS.md | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index 6eabaf05d24..c61293f424f 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -59,20 +59,30 @@ star, smile, etc.). Some good tips about code reviews can be found in our ## Feature Freeze -On the 7th of each month, the stable branches for the upcoming release will -be frozen for major changes. Merge requests may still be merged into master -during this period. By freezing the stable branches prior to a release there's -no need to worry about last minute merge requests potentially breaking a lot of +On the 7th of each month, RC1 of the upcoming release is released and the stable branch for this release is frozen, which means master is no longer merged into it. +Merge requests may still be merged into master during this period, +but they will go into the _next_ release, unless they are manually cherry-picked into the stable branch. +By freezing the stable branches prior to a release there's no need to worry +about last minute merge requests potentially breaking a lot of things. -What is considered to be a major change is determined on a case by case basis as -this definition depends very much on the context of changes. For example, a 5 -line change might have a big impact on the entire application. Ultimately the -decision will be made by the maintainers and the release managers. +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, and released in the next RC (before the 22nd) or patch release (after the 22nd). + +If your merge request does not meet that requirement but you still think it should go into the upcoming release, +you can ask for an exception to be made. +To make sure the advantages and disadvantages are well considered, exceptions require sign-off from 3 people besides the developer: a Release Manager, the relevant engineering lead, and an engineering director, VP, or CTO. + +You and they should weigh the benefit and urgency of the change (how important it is to the company that this is released _right now_ instead of in a month) +against the potential negative impact (things breaking without enough time to comfortably find them and fix them before the release on the 22nd). +When in doubt, we err on the side of _not_ cherry-picking. + +For example, an exception may be made for a trivial 1-5 line performance improvement +(e.g. adding an 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. Merge requests without a milestone and this label will +~"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. ## Copy & paste responses -- cgit v1.2.1 From 7fd0934f5aa4badad30e6ce696ac3893987cda2d Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Wed, 8 Feb 2017 15:31:36 -0600 Subject: Small rephrase --- PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index c61293f424f..53a6dc4fad9 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -76,7 +76,7 @@ You and they should weigh the benefit and urgency of the change (how important i against the potential negative impact (things breaking without enough time to comfortably find them and fix them before the release on the 22nd). When in doubt, we err on the side of _not_ cherry-picking. -For example, an exception may be made for a trivial 1-5 line performance improvement +For example, it is likely that an exception will be made for a trivial 1-5 line performance improvement (e.g. adding an 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 -- cgit v1.2.1 From 6f6100b562b64fbb42f999dfa4eecfc404896aac Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Wed, 8 Feb 2017 15:42:40 -0600 Subject: Too many releases --- PROCESS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PROCESS.md b/PROCESS.md index 53a6dc4fad9..eaf388be369 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -59,7 +59,7 @@ star, smile, etc.). Some good tips about code reviews can be found in our ## Feature Freeze -On the 7th of each month, RC1 of the upcoming release is released and the stable branch for this release is frozen, which means master is no longer merged into it. +On the 7th of each month, RC1 of the upcoming release is created and deployed to GitLab.com and the stable branch for this release is frozen, which means master is no longer merged into it. Merge requests may still be merged into master during this period, but they will go into the _next_ release, unless they are manually cherry-picked into the stable branch. By freezing the stable branches prior to a release there's no need to worry -- cgit v1.2.1 From 5d55156950bbc0a1878acf2b9513de7d97449a89 Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Wed, 8 Feb 2017 17:14:03 -0600 Subject: Rephrase some things --- PROCESS.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index eaf388be369..f7d1aa03b6e 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -62,22 +62,24 @@ star, smile, etc.). Some good tips about code reviews can be found in our On the 7th of each month, RC1 of the upcoming release is created and deployed to GitLab.com and the stable branch for this release is frozen, which means master is no longer merged into it. Merge requests may still be merged into master during this period, but they will go into the _next_ release, unless they are manually cherry-picked into the stable branch. -By freezing the stable branches prior to a release there's no need to worry -about last minute merge requests potentially breaking a lot of -things. +By freezing the stable branches 2 weeks prior to a release, we reduce the risk of a last minute merge request potentially breaking a lot of things. -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, and released in the next RC (before the 22nd) or patch release (after the 22nd). +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 released in the next RC (before the 22nd) or patch release (after the 22nd). -If your merge request does not meet that requirement but you still think it should go into the upcoming release, -you can ask for an exception to be made. -To make sure the advantages and disadvantages are well considered, exceptions require sign-off from 3 people besides the developer: a Release Manager, the relevant engineering lead, and an engineering director, VP, or CTO. +If you think a merge request should go into the upcoming release 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: a Release Manager (1), a relevant Engineering Lead (2), and an Engineering Director, VP of Engineering, or CTO (3). -You and they should weigh the benefit and urgency of the change (how important it is to the company that this is released _right now_ instead of in a month) -against the potential negative impact (things breaking without enough time to comfortably find them and fix them before the release on the 22nd). +Whether an exception is made is determined by weighing the benefit and urgency of the change +(how important it is to the company that this is released _right now_ instead of in a month) +against the potential negative impact +(things breaking without enough time to comfortably find and fix them before the release on the 22nd). 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 an index or adding `includes` to a query), but not for a new feature, no matter how relatively small or thoroughly tested. +(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 -- cgit v1.2.1 From d3333c34a1c024f012030189c559340ffc991dc0 Mon Sep 17 00:00:00 2001 From: Douwe Maan Date: Wed, 8 Feb 2017 17:44:52 -0600 Subject: Add an ordered list with the 3 people who need to sign off --- PROCESS.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/PROCESS.md b/PROCESS.md index f7d1aa03b6e..f257c1d5358 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -62,7 +62,7 @@ star, smile, etc.). Some good tips about code reviews can be found in our On the 7th of each month, RC1 of the upcoming release is created and deployed to GitLab.com and the stable branch for this release is frozen, which means master is no longer merged into it. Merge requests may still be merged into master during this period, but they will go into the _next_ release, unless they are manually cherry-picked into the stable branch. -By freezing the stable branches 2 weeks prior to a release, we reduce the risk of a last minute merge request potentially breaking a lot of things. +By freezing the stable branches 2 weeks prior to a release, we reduce the risk of a last minute merge request potentially breaking things. 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. @@ -70,7 +70,13 @@ Any merge requests cherry-picked into the stable branch for a previous release w These fixes will be released in the next RC (before the 22nd) or patch release (after the 22nd). If you think a merge request should go into the upcoming release 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: a Release Manager (1), a relevant Engineering Lead (2), and an Engineering Director, VP of Engineering, or CTO (3). +you can ask for an exception to be made. Exceptions require sign-off from 3 people besides the developer: + +1. a Release Manager +2. an Engineering Lead +3. an Engineering Director, the VP of Engineering, or the CTO + +You can find who is who on the [team page](https://about.gitlab.com/team/). Whether an exception is made is determined by weighing the benefit and urgency of the change (how important it is to the company that this is released _right now_ instead of in a month) -- cgit v1.2.1