diff options
Diffstat (limited to 'PROCESS.md')
| -rw-r--r-- | PROCESS.md | 32 |
1 files changed, 27 insertions, 5 deletions
diff --git a/PROCESS.md b/PROCESS.md index 1cc5b44aa67..a06ddb68b77 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) @@ -199,7 +201,7 @@ you can ask for an exception to be made. Check [this guide](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md) about how to open an exception request before opening one. -### 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 @@ -217,10 +219,30 @@ 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, especially if they affect +users. Despite that, ~regression label itself does not imply when the issue +will be scheduled. + +When a regression is found: +1. Create an issue describing the problem in the most detailed way possible +1. If possible, provide links to real examples and how to reproduce the problem +1. Label the issue properly, using the [team label](../CONTRIBUTING.md#team-labels), + the [subject label](../CONTRIBUTING.md#subject-labels) + and any other label that may apply in the specific case +1. Add the ~bug and ~regression labels +1. Notify the respective Engineering Manager to evaluate the Severity of the regression and add a [Severity label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-severity-labels). The counterpart Product Manager is included to weigh-in on prioritization as needed to set the [Priority label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-priority-labels). +1. If the regression is either an ~S1, ~S2 or ~S3 severity, label the regression with the current milestone as it should be fixed in the current milestone. + 1. If the regression was introduced in an RC of the current release, label with ~Deliverable + 1. If the regression was introduced in the previous release, label with ~"Next Patch Release" +1. If the regression is an ~S4 severity, the regression may be scheduled for later milestones at the discretion of Engineering Manager and Product Manager. + +When a new issue is found, the fix should start as soon as possible. You can +ping the Engineering Manager or the Product Manager for the relative area to +make them aware of the issue earlier. They will analyze the priority and change +it if needed. ## Release retrospective and kickoff |