QA:SOP freeze exception bug process
Fedora uses a system of tracker bugs to keep track of nice-to-have (NTH) bugs - bugs which do not block a given pre-release or release, but which are considered high priority for tracking and fixing, and for which fixes will be accepted even during the freeze period for that release. This page defines the process by which bugs are proposed, reviewed and accepted as nice-to-have bugs, and how nice-to-have bugs are then tracked.
See also the blocker bug process, which defines the similar process for blocker bugs - bugs that are blocking the release of its pre- and final releases and which must be fixed before these releases can proceed.
Proposing nice-to-have bugs
Only bugs reported against a Fedora component in Red Hat Bugzilla can be marked as nice-to-have for a Fedora release. If the bug you wish to mark as a nice-to-have is being tracked in an upstream bug tracking system, you must file a corresponding bug in the Fedora bug tracking system before proposing it.
To propose a bug as a nice-to-have for a release, mark it as blocking the tracker bug for nice-to-have 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 nice-to-have tracker bugs follow a consistent naming scheme. The Alpha tracker will always be called FXXAlpha-accepted, the Beta tracker will always be called FXXBeta-accepted, and the final release tracker will always be called FXX-accepted, where XX is the number of the release in question. So, to mark a bug as a nice-to-have for the release of Fedora 14 Beta, you would set it to block the bug F14Beta-accepted.
Reviewing nice-to-have bugs
Proposed blockers are reviewed and either accepted or rejected as blockers in collaboration between the QA, Development and ReleaseEngineering groups. This is mostly done during weekly meetings for the express purpose of reviewing nice-to-have bugs: the procedure followed during these meetings is documented here. Note that in practice, the NTH meeting is usually rolled into the blocker review meeting. Blocker review meetings usually occur every Friday during release periods, but special review meetings can be scheduled at other times when necessary. When appropriate, proposed nice-to-have bugs may also be reviewed between meetings or during other meetings, such as 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 nice-to-have.
Bugs that are accepted as nice-to-have for the relevant release will be marked with the Whiteboard field AcceptedNTH. Bugs which are rejected will be updated to no longer block the relevant tracker bug, and have the RejectedNTH Whiteboard field added so that if they are proposed 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 nice-to-have status should also be documented with a comment.
Tracking nice-to-have bugs
Again, tracking nice-to-have bugs and making a best effort to fix them is a collaborative effort between the QA, Development and Release Engineering groups. The QA:SOP_NTH_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 nice-to-have bugs. After blocker bugs, QA group members are encouraged to prioritize testing of nice-to-have bug fixes, development group members are encouraged to prioritize developing fixes for nice-to-have bugs, and release engineering group members are encouraged to prioritize the release of fixes for nice-to-have bugs (after appropriate testing). Each group should have its own processes for ensuring its responsibilities in relation to nice-to-have bugs are met.
In Bugzilla, nice-to-have 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 nice-to-have 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.