Commit 347ecbb6 authored by Mek Stittri's avatar Mek Stittri

Collaspe regression under bugs

- Bugs are the parent section
- Use the same workflow but branch off bugs / regression sections
- Addressed review comments
parent e3b005fe
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment