|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| == Background ==
| | #REDIRECT [[QA:SOP_blocker_bug_process]] |
| | |
| Fedora uses a system of ''tracker bugs'' to keep track of ''release blocker bugs'' - bugs that are blocking the release of its pre- and final releases 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 [[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.
| |
| | |
| == Proposing blocker bugs ==
| |
| | |
| 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 an alias or bug ID of the ''tracker bug'' into the '''Blocks:''' field in Bugzilla. The aliases for the ''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 blocking 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 blocking the release of {{FedoraVersion|long|next}} Beta, you would set it to block the bug '''BetaBlocker'''. When proposing a bug as a blocker, you should always explicitly state which of the [[Fedora_Release_Criteria]] you consider it to be infringing (see [[BugZappers/StockBugzillaResponses#Blocker_Bug_Addition|example]]). You can find a complete list of blocker 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 blocking 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 as a blocker.}}
| |
| | |
| == 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 bugs: the procedure followed during these meetings is documented [[QA:SOP_Blocker_Bug_Meeting|here]]. Blocker review meetings usually occur every Friday during release periods, but special review meetings can be scheduled at other times when necessary. Blocker review meetings are public, and reporters who propose a bug as a release blocker are allowed and indeed encouraged to attend the meeting where it is reviewed. When appropriate, proposed blockers may also be reviewed between meetings or during other meetings, such as 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. 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</code>. Bugs which are rejected as blockers will be updated to no longer block the relevant ''tracker bug'', and have the <code>RejectedBlocker</code> 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.
| |
| | |
| == 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 [[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. 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.
| |
| | |
| [[Category:QA SOPs]]
| |
