diff options
author | Fabio Busatto <fabio@gitlab.com> | 2018-03-05 19:39:23 +0300 |
---|---|---|
committer | bikebilly <fabio@gitlab.com> | 2018-06-18 15:44:14 +0300 |
commit | 8f335b27b04d1a862f654cd99cce0f5ee98b63af (patch) | |
tree | 2814f274e7f9d310204cd1555b1ee1e18919afe6 | |
parent | 519d0477e2e5e495e8476c460e4ae233e26de3c4 (diff) |
Add how to manage a regression
-rw-r--r-- | PROCESS.md | 36 |
1 files changed, 31 insertions, 5 deletions
diff --git a/PROCESS.md b/PROCESS.md index a46fd8c25b4..5fdab3ed382 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -15,6 +15,8 @@ - [Between the 1st and the 7th](#between-the-1st-and-the-7th) - [On the 7th](#on-the-7th) - [After the 7th](#after-the-7th) +- [Regressions](#regressions) + - [How to manage a regression](#how-to-manage-a-regression) - [Release retrospective and kickoff](#release-retrospective-and-kickoff) - [Retrospective](#retrospective) - [Kickoff](#kickoff) @@ -216,7 +218,7 @@ For example, it is likely that an exception will be made for a trivial 1-5 line All MRs which have had exceptions granted must be merged by the 15th. -### Regressions +## 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 @@ -234,10 +236,33 @@ 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. -A regression issue should be labeled with the appropriate [subject label](../CONTRIBUTING.md#subject-labels-wiki-container-registry-ldap-api-etc) -and [team label](../CONTRIBUTING.md#team-labels-ci-discussion-edge-platform-etc), -just like any other issue, to help GitLab team members focus on issues that are -relevant to [their area of responsibility](https://about.gitlab.com/handbook/engineering/workflow/#choosing-something-to-work-on). +### How to manage a regression + +Regressions are very important, and they should be considered high priority +issues that should be solved as soon as possible, expecially if they affect +users. Anyway, ~regression label itself is not a [priority label], and this +means that regressions should still follow the scheduling process. + +When a regression is found: +1. Create an issue describing the problem in the most detailed way possible +2. Label the issue properly, using the [team label](../CONTRIBUTING.md#team-labels-ci-discussion-edge-platform-etc), + the [subject label](../CONTRIBUTING.md#subject-labels-wiki-container-registry-ldap-api-etc) + and any other label that may apply in the specific case +3. Add the ~regression label +4. Add the proper milestone +4. Ping the Product Manager, see [product categories](https://about.gitlab.com/handbook/product/categories/) + to find who manages that specific area of the Product + +A very important step is helping the PM to understand the impact the regression +may have on users, by providing examples and how to reproduce it. This will +allow proper scheduling with a [priority label]. Normally it will be +~"Next Patch Release" if after the final release, or ~Deliverable if between the +feature freeze and the final release. + +In case of very urgent fixes, a developer can choose to pick up the issue even +before it is properly scheduled, in order to speed up the process. The PM should +be pinged in the issue anyway to get confirmation about the actual priority as +soon as possible. ## Release retrospective and kickoff @@ -312,3 +337,4 @@ still an issue I encourage you to open it on the [GitLab.com issue tracker](http [done]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#definition-of-done [automatic_ce_ee_merge]: https://docs.gitlab.com/ce/development/automatic_ce_ee_merge.html [ee_features]: https://docs.gitlab.com/ce/development/ee_features.html +[priority label]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#priority-labels-deliverable-stretch-next-patch-release |