diff options
Diffstat (limited to 'PROCESS.md')
-rw-r--r-- | PROCESS.md | 117 |
1 files changed, 73 insertions, 44 deletions
diff --git a/PROCESS.md b/PROCESS.md index a06ddb68b77..583f36b820f 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -15,8 +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) -- [Regressions](#regressions) - - [How to manage a regression](#how-to-manage-a-regression) +- [Bugs](#bugs) + - [Regressions](#regressions) + - [Managing bugs](#managing-bugs) - [Release retrospective and kickoff](#release-retrospective-and-kickoff) - [Retrospective](#retrospective) - [Kickoff](#kickoff) @@ -115,6 +116,11 @@ target. However, if one does and falls into either of the above categories, it's the reviewer's responsibility to manage the above communication and assignment on behalf of the community member. +Every new feature or change should be shipped with its corresponding documentation +in accordance with the +[documentation process](https://docs.gitlab.com/ee/development/documentation/workflow.html) +and [structure](https://docs.gitlab.com/ee/development/documentation/structure.html). + #### What happens if these deadlines are missed? If a small or large feature is _not_ with a maintainer or reviewer by the @@ -140,14 +146,9 @@ and to prevent any last minute surprises. ### On the 7th -Merge requests should still be complete, following the -[definition of done][done]. The single exception is documentation, and this can -only be left until after the freeze if: +Merge requests should still be complete, following the [definition of done][done]. -* There is a follow-up issue to add documentation. -* It is assigned to the person writing documentation for this feature, and they - are aware of it. -* It is in the correct milestone, with the ~Deliverable label. +#### Feature merge requests If a merge request is not ready, but the developers and Product Manager responsible for the feature think it is essential that it is in the release, @@ -163,15 +164,32 @@ information, see [Automatic CE->EE merge][automatic_ce_ee_merge] and [Guidelines for implementing Enterprise Edition features][ee_features]. +#### Documentation merge requests + +Documentation is part of the product and must be shipped with the feature. + +The single exception for the feature freeze is documentation, and it can +be left to be **merged up to the 14th** if: + +* There is a follow-up issue to add documentation. +* It is assigned to the developer writing documentation for this feature, and they + are aware of it. +* It is in the correct milestone, with the labels ~Documentation, ~Deliverable, +~missed-deliverable, and "pick into X.Y" applied. +* It must be reviewed and approved by a technical writer. + +For more information read the process for +[documentation shipped late](https://docs.gitlab.com/ee/development/documentation/workflow.html#documentation-shipped-late). + ### After the 7th Once the stable branch is frozen, the only MRs that can be cherry-picked into the stable branch are: -* Fixes for [regressions](#regressions) +* Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section. * Fixes for security issues * Fixes or improvements to automated QA scenarios -* Documentation updates for changes in the same release +* [Documentation updates](https://docs.gitlab.com/ee/development/documentation/workflow.html#documentation-shipped-late) for changes in the same release * New or updated translations (as long as they do not touch application code) During the feature freeze all merge requests that are meant to go into the @@ -201,48 +219,59 @@ 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 +## Bugs + +A ~bug is a defect, error, failure which causes the system to behave incorrectly or prevents it from fulfilling 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](../CONTRIBUTING.md#severity-labels) + +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. -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 -features that were only added in that monthly release. Every regression **must** -have the milestone of the release it was introduced in - if a regression doesn't -have a milestone, it might be 'just' a bug! +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. -For instance, if 10.5.0 adds a feature, and that feature doesn't work correctly, -then this is a regression in 10.5. If 10.5.1 then fixes that, but 10.5.3 somehow -reintroduces the bug, then this bug is still a regression in 10.5. +A regression should always have the `regression:xx.x` label on it to designate when it was introduced. -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 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. +Regressions should be considered high priority issues that should be solved as soon as possible, especially if they have severe impact on users. -### How to manage a regression +### Managing bugs -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. +**Prioritization:** We give higher priority to regressions on features that worked in the last recent monthly release and the current release candidates. +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 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. 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. +1. Notify the respective Engineering Manager to evaluate and apply the [Severity label](../CONTRIBUTING.md#bug-severity-labels) and [Priority label](../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 and add the corresponding `regression:xx.x` label. + 1. If the affected release version can't be determined, add the generic ~regression label for the time being. + 1. If the affected version `xx.x` in `regression:xx.x` is the **current release**, it's recommended to schedule the fix for the current milestone. + 1. This falls under regressions which worked in the last release and the current RCs. More detailed explanations in the **Prioritization** section above. + 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, it's recommended to schedule the fix for the current milestone. We would like to fix the highest severity regression as soon as we can. + 1. If the regression is an ~S2, ~S3 or ~S4 severity, the regression may be scheduled for later milestones at the discretion of the Engineering Manager and Product Manager. ## Release retrospective and kickoff |