summaryrefslogtreecommitdiff
path: root/PROCESS.md
diff options
context:
space:
mode:
Diffstat (limited to 'PROCESS.md')
-rw-r--r--PROCESS.md80
1 files changed, 31 insertions, 49 deletions
diff --git a/PROCESS.md b/PROCESS.md
index b773458fccc..a97e3beb92e 100644
--- a/PROCESS.md
+++ b/PROCESS.md
@@ -15,11 +15,9 @@
- [Between the 1st and the 7th](#between-the-1st-and-the-7th)
- [On the 7th](#on-the-7th)
- [After the 7th](#after-the-7th)
-- [Defects](#defects)
- - [Bugs](#bugs)
- - [Managing a bug](#managing-a-bug)
+- [Bugs](#bugs)
- [Regressions](#regressions)
- - [Managing a regression](#managing-a-regression)
+ - [Managing bugs](#managing-bugs)
- [Release retrospective and kickoff](#release-retrospective-and-kickoff)
- [Retrospective](#retrospective)
- [Kickoff](#kickoff)
@@ -171,7 +169,7 @@ information, see
Once the stable branch is frozen, the only MRs that can be cherry-picked into
the stable branch are:
-* Fixes for [regressions](#regressions), where `regression:xx.x` is the last recent monthly release or the current release.
+* Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing a regression](#managing-a-regression).
* Fixes for security issues
* Fixes or improvements to automated QA scenarios
* Documentation updates for changes in the same release
@@ -204,74 +202,58 @@ 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.
-## Defects
+## Bugs
-We categorize defects into 2 main categories, a ~bug and a ~regression.
-
-Whether the defect is a bug or a regression, the triage process 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 and prioritize the work as needed.
-
-### Bugs
-
-A ~bug ia a defect, error, failure which causes the system to behave incorrectly or preventing it from fulfill the product requirements.
+A ~bug is a defect, error, failure which causes the system to behave incorrectly or prevents it from fulfilling from fulfill the product requirements.
The level of impact of a ~bug can vary from blocking a whole functionality
or a feature usability bug. A bug should always be linked to a severity level.
Refer to our [severity levels](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#severity-labels)
-#### Managing a Bug
-
-When a regression is created:
-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 label
-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. From the Severity and Priority level the Engineering Manager then decides which milestone to set on the bug.
+Whether the bug is also a regression or not, the triage process should start as soon as possible.
+Ensure that the Engineering Manager and/or the Product Manager for the relative area is involved to prioritize the work as needed.
### Regressions
A ~regression implies that a previously **verified working functionality** no longer works.
Regressions are a subset of bugs. We use the ~regression label to imply that the defect caused the functionality to regress.
+The label tells us that something worked before and it needs extra attention from Engineering and Product Managers to schedule/reschedule.
-The regression label does not apply to ~bugs for new features to which functionality was **never verified as working**.
-That by definition are not regressions. The ~regression label is not removed as part of any rescheduling process.
-If an issue is indeed a regression, it should carry such context forward until it's fully resolved.
+The regression label does not apply to ~bugs for new features for which functionality was **never verified as working**.
+These, by definition, are not regressions.
A regression should always have the `regression:xx.x` label on it to designate when it was introduced.
-#### Managing a Regression
-
-A ~regression label tells us that something worked before and it needs extra attention from Engineering and Product Managers to schedule/reschedule.
-
Regressions should be considered high priority issues that should be solved as soon as possible, especially if they have severe impact on users.
+### Managing bugs
+
**Prioritization** We give higher priority to regressions that affected the last recent monthly release and the current release candidates.
-The two scenarios below can [by pass the exception request in the release process](LINK_HERE_TO_RM_DOC)
-* A regression in the **Last recent monthly release**
- * **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works this is regression for 11.0. The issue should have the `regression:11.0` label.
+The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version.
+* A regression which worked in the **Last monthly release**
+ * **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
* *Note:* When we say `the last 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 in the **Current release candidates**
- * **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works this is regression for 11.1. The issue should have the `regression:11.1` label.
+* A regression which worked in the **Current release candidates**
+ * **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
* *Note:* 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 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
+When a bug 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. Determine the release that the regression affects. Add the `regression:xx.x` label.
-1. If the `regression:xx.x` is the **Current release**, schedule it for the current milestone as it should be fixed in the current milestone. Scope it with ~Deliverable.
-1. If the `regression:xx.x` is the **Last monthly release**, schedule it for the current milestone as it should be fixed in the current milestone. Scope it with ~"Next Patch Release".
-1. If the `regression:xx.x` is older than the **Current release** and **Last monthly release**:
- 1. If the regression is an ~S1 severity, label the regression with the current milestone as it should be fixed in the current milestone. Scope it with ~Stretch.
- 1. If the regression is an ~S2, ~S3 or ~S4 severity, the regression may be scheduled for later milestones at the discretion of Engineering Manager and Product Manager.
+1. If the ~bug is a **regression**, add the ~regression label.
+1. Notify the respective Engineering Manager to evaluate the Severity and add a [Severity label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-severity-labels) and [Priority label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-priority-labels).
+The counterpart Product Manager is included to weigh-in on prioritization as needed.
+1. If the ~bug is **NOT** a regression:
+ 1. The Engineering Manager decides which milestone the bug will be fixed. The appropriate milestone is applied.
+1. If the bug is a ~regression:
+ 1. Determine the release that the regression affects. Add the corresponding `regression:xx.x` label. See **Prioritization** section above.
+ 1. If the affected version `xx.x` in `regression:xx.x` is the **Current release**, schedule it for the current milestone as it should be fixed in the current milestone. Scope it with ~Deliverable.
+ 1. If the affected version `xx.x` in `regression:xx.x` is older than the **Current release**
+ 1. If the regression is an ~S1 severity, label the regression with the current milestone as it should be fixed in the current milestone. Scope it with ~"Next Patch Release" or ~Stretch.
+ 1. If the regression is an ~S2, ~S3 or ~S4 severity, the regression may be scheduled for later milestones at the discretion of Engineering Manager and Product Manager.
## Release retrospective and kickoff