(fork) |
(expand templates) |
||
Line 4: | Line 4: | ||
See also the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]], which defines the similar process for freeze exception bugs - those which do not block the release, but which are considered high priority for tracking and fixing and for which fixes will be accepted even during release freezes. | See also the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]], which defines the similar process for freeze exception bugs - those which do not block the release, but which are considered high priority for tracking and fixing and for which fixes will be accepted even during release freezes. | ||
{{ | |||
{{ | == Schedule == | ||
{{ | Or, '''when does this process affect me?''' | ||
The process of nominating and reviewing blocker bugs is active to some degree at all times. It is particularly visible, however, after the [[Milestone freezes]] for each milestone of a release (Alpha, Beta, Final). At the ''Milestone freeze'' (''Alpha freeze'', ''Beta freeze'' etc), the stable [[Repositories#fedora|''fedora'']] package repository is frozen, meaning packages can no longer move from the [[Repositories#updates-testing|updates-testing]] repository to the ''stable'' repository from which the [[QA:SOP_compose_request|test compose and release candidate]] builds are created. | |||
If a Fedora milestone release is currently in a milestone freeze (you can check [[Releases/{{FedoraVersionNumber|next}}/Schedule|the schedule for the next release here]]) and you are a packager or tester and you believe a build of your package or a package you are testing should be in the milestone release, this process concerns you. After the ''milestone freeze'', the build can only be promoted to 'stable' and included in the release if it fixes a bug that is granted blocker or freeze exception status. | |||
After the milestone release is finished, the ''milestone freeze'' is lifted and builds can be marked as ''stable'' again without following this process, so if the build can wait until after the milestone release, you do not need to follow this process. | |||
== Proposing blocker bugs == | |||
You can use the [https://qa.fedoraproject.org/blockerbugs/propose_bug Blocker Bugs web application] to propose a bug as a blocker. It will guide you through the process. | |||
=== Manual process === | |||
If you have an issue with the guided process or want to propose a blocker directly from Bugzilla for efficiency, you can use the manual process. | |||
To propose a bug as a blocker for a release, mark it as blocking the ''tracker bug'' for blocker bugs in that release. To do this, enter the alias or bug ID of the ''tracker bug'' into the '''Blocks:''' field in Bugzilla. The aliases for the blocker ''tracker bugs'' follow a consistent naming scheme. For the next release, the Alpha tracker will always be called '''AlphaBlocker''', the Beta tracker will always be called '''BetaBlocker''', and the final release tracker will always be called '''FinalBlocker'''. Rarely, you may need to propose a bug as a blocker for the next release but one - in this case, prepend '''FXX''' (where XX is the release number) to the name of the alias, e.g. '''F{{FedoraVersionNumber|next2}}AlphaBlocker'''. So, to mark a bug as a blocker for the release of {{FedoraVersion|long|next}} Beta, you would set it to block the bug '''BetaBlocker'''. You can find a full list of tracker bugs at [[BugZappers/HouseKeeping/Trackers]]. | |||
{{admon/important|Must use [http://bugzilla.redhat.com Red Hat Bugzilla]|Only bugs reported against a Fedora component in [http://bugzilla.redhat.com Red Hat Bugzilla] can be marked as blockers for a Fedora release. If the bug you wish to mark as a blocker is being tracked in an upstream bug tracking system, you must file a corresponding bug in the Fedora bug tracking system before proposing it.}} | |||
== Reviewing blocker bugs == | |||
Proposed blockers are reviewed and either ''accepted'' or ''rejected'' as blockers in collaboration between three stakeholder groups: [[QA]], [[Development]] and [[ReleaseEngineering]]. This is mostly done during weekly meetings for the express purpose of reviewing blocker and freeze exception bugs: the procedure followed during these meetings is documented [[QA:SOP_Blocker_Bug_Meeting|here]]. Blocker review meetings usually occur every Monday - immediately after the [[QA/Meetings|QA meeting]] - so long as there is at least one proposed blocker, but special review meetings can be scheduled at other times when necessary. They are always announced to the {{fplist|test-announce}} mailing list, which is CC'ed to {{fplist|devel}}. The blocker review meetings are public, and reporters who propose a bug as a blocker are allowed and indeed encouraged to attend the meeting where it is reviewed. | |||
When appropriate, proposed blockers may also be reviewed between meetings by Bugzilla comment discussion, or during the [[Go_No_Go_Meeting|''engineering readiness meeting'']] (also known as a ''go/no-go meeting'') which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a blocker. However, review should not be done as part of [[QA/Meetings|QA meetings]]. If blocker review is required or desirable at the time of a QA meeting, a proper blocker bug review meeting should be convened immediately following the QA meeting. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process| |Bugs which are rejected as blockers can be considered for the [[QA:SOP_freeze_exception_bug_process|freeze exception bug process]].}} | |||
Bugs that are accepted as blockers for the relevant release will be marked with the Whiteboard field {{code|AcceptedBlocker}}{{#ifeq:blocker|blocker|, {{code|Accepted0Day}} or {{code|AcceptedPreviousRelease}} (see below for details on these)|}}. Bugs which are rejected as blockers will be updated to no longer block the relevant ''tracker bug'', and have the {{code|RejectedBlocker}} Whiteboard field added so that if they are proposed as blockers again, it is clear they have already been considered and rejected. Therefore, a bug which has been proposed but not accepted or rejected can be identified by the lack of a relevant Whiteboard field. All changes to blocker status should also be documented with a comment. The comment should explain the rationale behind the decision and should link to the summary or logs of the meeting at which the decision was made. | |||
=== Normal, 0-Day and Previous Release blockers === | === Normal, 0-Day and Previous Release blockers === | ||
Line 12: | Line 41: | ||
The most common case for both {{code|Accepted0Day}} and {{code|AcceptedPreviousRelease}} is upgrade-related problems. For instance, there may be a bug in the upgrade mechanism itself; this will usually need to be fixed in the existing stable releases, not the new release. There may be a bug in a package in the new release which prevents systems with that package installed upgrading correctly; the fix for such a bug does not need to be part of the frozen final release, as upgrades typically use the online package repositories, but if the affected package is very commonly installed, we may decide that we wish to ensure the fixed package is available from the updates repository on release day, and make the bug an accepted 0-Day blocker. | The most common case for both {{code|Accepted0Day}} and {{code|AcceptedPreviousRelease}} is upgrade-related problems. For instance, there may be a bug in the upgrade mechanism itself; this will usually need to be fixed in the existing stable releases, not the new release. There may be a bug in a package in the new release which prevents systems with that package installed upgrading correctly; the fix for such a bug does not need to be part of the frozen final release, as upgrades typically use the online package repositories, but if the affected package is very commonly installed, we may decide that we wish to ensure the fixed package is available from the updates repository on release day, and make the bug an accepted 0-Day blocker. | ||
{{ | |||
{{ | == Automatic blockers == | ||
Certain types of bugs are considered ''automatic blockers''. These bugs can be marked as accepted by any member of one of the stakeholder groups without formal review. A comment should accompany this change, explaining that it has been made under the ''automatic blocker'' policy and linking to this section of this page. If anyone believes that a bug has been incorrectly marked as AcceptedBlocker in this way, they may propose that it be formally reviewed by appending a comment to the bug or by raising it during a blocker review meeting. '''Only''' the following types of bug are considered ''automatic blockers''. {{#ifeq:{{PAGENAME}}|SOP freeze exception bug process||Note that | |||
where an item on this list applies to release-blocking images, a corresponding issue in a non-release-blocking image would likely be an ''automatic freeze exception'', under the corresponding [[QA:SOP_freeze_exception_bug_process#Automatic_freeze_exceptions|policy]].}} | |||
* Bugs which entirely prevent the composition of one or more of the release-blocking images required to be built for a currently-pending (pre-)release | |||
* Incorrect checksums present on any of the release-blocking TC/RC images (failures of [[QA:Testcase_Mediakit_ISO_Checksums]]) | |||
* Unresolved dependencies on a release-blocking DVD-style (offline installer) image (failures of [[QA:Testcase_Mediakit_Repoclosure]]) | |||
* File conflicts between two packages on a release-blocking DVD-style (offline installer) image without an explicit Conflicts: tag (failures of [[QA:Testcase_Mediakit_FileConflicts]]) | |||
* Complete failure of any release-blocking TC/RC image to boot at all under any circumstance - "DOA" image (conditional failure is not an automatic blocker) | |||
* Any release-blocking Beta or Final TC/RC image exceeding its target size (failures of [[QA:Testcase_Mediakit_ISO_Size]]) | |||
{{#ifeq:{{PAGENAME}}|SOP freeze exception bug process||* Bugs designated as blockers by FESCo (see [[{{FedoraVersion|long|next}}_Alpha_Release_Criteria#FESCo_blocker_bugs]])}} | |||
No other type of bug can be considered an ''automatic blocker'' under any circumstance. In particular, "I think it is obviously a blocker" is not a valid reason to use this procedure. If you believe another type of bug should be added to the list, please propose the change on the | |||
[https://lists.fedoraproject.org/mailman/listinfo/test test@ mailing list]. | |||
== Tracking blocker bugs == | |||
Again, tracking blocker bugs and ensuring that they are fixed is a collaborative effort between the QA, Development and Release Engineering groups. The [[QA:SOP_Blocker_Bug_Meeting]] process includes reviewing the status of existing blockers and ensuring that the appropriate resources to fix them are in place, as well as evaluating proposed blockers.{{#ifeq:{{PAGENAME}}|SOP freeze exception bug process|After blocker bugs,|}} QA group members are encouraged to prioritize testing of blocker bug fixes, development group members are encouraged to prioritize developing fixes for blocker bugs, and release engineering group members are encouraged to prioritize the release of fixes for blocker bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to blocker bugs are met. | |||
In Bugzilla, blocker bugs should follow the normal [[BugZappers/BugStatusWorkFlow|workflow]], with special attention paid by the development group to submitting proposed fixes to the updates-testing repository so they reach '''MODIFIED''' and '''ON_QA''' status, and special attention paid by the QA group to testing proposed fixes and setting ones that are tested successfully to the '''VERIFIED''' status.{{#ifeq:{{PAGENAME}}|SOP freeze exception bug process| Builds that fix freeze exception bugs should be pulled into TC and RC builds by the release engineering team as long as they are submitted as proposed updates and meet the necessary karma requirements.|}} No blocker bug should be set to '''CLOSED ERRATA''' until a fix is actually released to the stable repository for the release in question: if a working fix is added to a test candidate or release candidate build, but not yet pushed to the stable repository, the bug should not be marked '''CLOSED ERRATA''', as this may result in the fix not being pushed to the stable repository and the fix accidentally omitted from the next candidate build as it is no longer possible to track the bug. | |||
== See also == | == See also == | ||
* [[Blocker Bug FAQ]] | * [[Blocker Bug FAQ]] |
Revision as of 14:55, 19 February 2016
Background
Fedora uses a system of tracker bugs to keep track of release blocker bugs - bugs that are blocking its milestone releases (Alpha, Beta, Final) and which must be fixed before these releases can proceed. The Fedora_Release_Criteria should be used to determine whether a bug is a blocker for a given release. This page defines the process by which bugs are proposed, reviewed and accepted as blocker bugs, and how blocker bugs are then tracked.
See also the freeze exception bug process, which defines the similar process for freeze exception bugs - those which do not block the release, but which are considered high priority for tracking and fixing and for which fixes will be accepted even during release freezes.
Schedule
Or, when does this process affect me?
The process of nominating and reviewing blocker bugs is active to some degree at all times. It is particularly visible, however, after the Milestone freezes for each milestone of a release (Alpha, Beta, Final). At the Milestone freeze (Alpha freeze, Beta freeze etc), the stable fedora package repository is frozen, meaning packages can no longer move from the updates-testing repository to the stable repository from which the test compose and release candidate builds are created.
If a Fedora milestone release is currently in a milestone freeze (you can check the schedule for the next release here) and you are a packager or tester and you believe a build of your package or a package you are testing should be in the milestone release, this process concerns you. After the milestone freeze, the build can only be promoted to 'stable' and included in the release if it fixes a bug that is granted blocker or freeze exception status.
After the milestone release is finished, the milestone freeze is lifted and builds can be marked as stable again without following this process, so if the build can wait until after the milestone release, you do not need to follow this process.
Proposing blocker bugs
You can use the Blocker Bugs web application to propose a bug as a blocker. It will guide you through the process.
Manual process
If you have an issue with the guided process or want to propose a blocker directly from Bugzilla for efficiency, you can use the manual process.
To propose a bug as a blocker for a release, mark it as blocking the tracker bug for blocker bugs in that release. To do this, enter the alias or bug ID of the tracker bug into the Blocks: field in Bugzilla. The aliases for the blocker tracker bugs follow a consistent naming scheme. For the next release, the Alpha tracker will always be called AlphaBlocker, the Beta tracker will always be called BetaBlocker, and the final release tracker will always be called FinalBlocker. Rarely, you may need to propose a bug as a blocker for the next release but one - in this case, prepend FXX (where XX is the release number) to the name of the alias, e.g. F43AlphaBlocker. So, to mark a bug as a blocker for the release of Fedora 42 Beta, you would set it to block the bug BetaBlocker. You can find a full list of tracker bugs at BugZappers/HouseKeeping/Trackers.
Reviewing blocker bugs
Proposed blockers are reviewed and either accepted or rejected as blockers in collaboration between three stakeholder groups: QA, Development and ReleaseEngineering. This is mostly done during weekly meetings for the express purpose of reviewing blocker and freeze exception bugs: the procedure followed during these meetings is documented here. Blocker review meetings usually occur every Monday - immediately after the QA meeting - so long as there is at least one proposed blocker, but special review meetings can be scheduled at other times when necessary. They are always announced to the test-announce mailing list, which is CC'ed to devel. The blocker review meetings are public, and reporters who propose a bug as a blocker are allowed and indeed encouraged to attend the meeting where it is reviewed.
When appropriate, proposed blockers may also be reviewed between meetings by Bugzilla comment discussion, or during the engineering readiness meeting (also known as a go/no-go meeting) which is convened to decide whether a release candidate should be approved as a final release. In these cases, consensus between the three stakeholder groups should still be reached in order to accept or reject a bug as a blocker. However, review should not be done as part of QA meetings. If blocker review is required or desirable at the time of a QA meeting, a proper blocker bug review meeting should be convened immediately following the QA meeting. Bugs which are rejected as blockers can be considered for the freeze exception bug process.
Bugs that are accepted as blockers for the relevant release will be marked with the Whiteboard field AcceptedBlocker, Accepted0Day or AcceptedPreviousRelease (see below for details on these). Bugs which are rejected as blockers will be updated to no longer block the relevant tracker bug, and have the RejectedBlocker Whiteboard field added so that if they are proposed as blockers again, it is clear they have already been considered and rejected. Therefore, a bug which has been proposed but not accepted or rejected can be identified by the lack of a relevant Whiteboard field. All changes to blocker status should also be documented with a comment. The comment should explain the rationale behind the decision and should link to the summary or logs of the meeting at which the decision was made.
Normal, 0-Day and Previous Release blockers
The whiteboard fields AcceptedBlocker, Accepted0Day and AcceptedPreviousRelease are used to distinguish between three categories of blocker bug. AcceptedBlocker is the most common case. This is used for bugs where the fix must appear as part of the final frozen release itself (usually, on one of the media). Accepted0Day is used for cases where the fix does not need to appear in the final frozen release, but must be available as an update on release day. AcceptedPreviousRelease is used for cases where the fix must appear as an update for one or more stable releases.
The most common case for both Accepted0Day and AcceptedPreviousRelease is upgrade-related problems. For instance, there may be a bug in the upgrade mechanism itself; this will usually need to be fixed in the existing stable releases, not the new release. There may be a bug in a package in the new release which prevents systems with that package installed upgrading correctly; the fix for such a bug does not need to be part of the frozen final release, as upgrades typically use the online package repositories, but if the affected package is very commonly installed, we may decide that we wish to ensure the fixed package is available from the updates repository on release day, and make the bug an accepted 0-Day blocker.
Automatic blockers
Certain types of bugs are considered automatic blockers. These bugs can be marked as accepted by any member of one of the stakeholder groups without formal review. A comment should accompany this change, explaining that it has been made under the automatic blocker policy and linking to this section of this page. If anyone believes that a bug has been incorrectly marked as AcceptedBlocker in this way, they may propose that it be formally reviewed by appending a comment to the bug or by raising it during a blocker review meeting. Only the following types of bug are considered automatic blockers. Note that where an item on this list applies to release-blocking images, a corresponding issue in a non-release-blocking image would likely be an automatic freeze exception, under the corresponding policy.
- Bugs which entirely prevent the composition of one or more of the release-blocking images required to be built for a currently-pending (pre-)release
- Incorrect checksums present on any of the release-blocking TC/RC images (failures of QA:Testcase_Mediakit_ISO_Checksums)
- Unresolved dependencies on a release-blocking DVD-style (offline installer) image (failures of QA:Testcase_Mediakit_Repoclosure)
- File conflicts between two packages on a release-blocking DVD-style (offline installer) image without an explicit Conflicts: tag (failures of QA:Testcase_Mediakit_FileConflicts)
- Complete failure of any release-blocking TC/RC image to boot at all under any circumstance - "DOA" image (conditional failure is not an automatic blocker)
- Any release-blocking Beta or Final TC/RC image exceeding its target size (failures of QA:Testcase_Mediakit_ISO_Size)
- Bugs designated as blockers by FESCo (see Fedora 42_Alpha_Release_Criteria#FESCo_blocker_bugs)
No other type of bug can be considered an automatic blocker under any circumstance. In particular, "I think it is obviously a blocker" is not a valid reason to use this procedure. If you believe another type of bug should be added to the list, please propose the change on the test@ mailing list.
Tracking blocker bugs
Again, tracking blocker bugs and ensuring that they are fixed is a collaborative effort between the QA, Development and Release Engineering groups. The QA:SOP_Blocker_Bug_Meeting process includes reviewing the status of existing blockers and ensuring that the appropriate resources to fix them are in place, as well as evaluating proposed blockers. QA group members are encouraged to prioritize testing of blocker bug fixes, development group members are encouraged to prioritize developing fixes for blocker bugs, and release engineering group members are encouraged to prioritize the release of fixes for blocker bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to blocker bugs are met.
In Bugzilla, blocker bugs should follow the normal workflow, with special attention paid by the development group to submitting proposed fixes to the updates-testing repository so they reach MODIFIED and ON_QA status, and special attention paid by the QA group to testing proposed fixes and setting ones that are tested successfully to the VERIFIED status. No blocker bug should be set to CLOSED ERRATA until a fix is actually released to the stable repository for the release in question: if a working fix is added to a test candidate or release candidate build, but not yet pushed to the stable repository, the bug should not be marked CLOSED ERRATA, as this may result in the fix not being pushed to the stable repository and the fix accidentally omitted from the next candidate build as it is no longer possible to track the bug.