Hi folks! So we agreed at Monday's meeting to go ahead with the plan to track non-media blockers using different whiteboard field magic words. We agreed to use 'Accepted0Day' and 'AcceptedPreviousRelease' as the magic words - 'AcceptedPreviousRelease' is a bit long and unwieldy to type, but we agreed it'd be the most clear. Here are the changes I propose making to the relevant wiki pages: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process 1. Amend "Bugs that are accepted as blockers for the relevant release will be marked with the Whiteboard field AcceptedBlocker." to read "Bugs that are accepted as blockers for the relevant release will be marked with the Whiteboard field text AcceptedBlocker, Accepted0Day or AcceptedPreviousRelease (see below for details on these)." 2. Add the following as a sub-section of the 'Reviewing blocker bugs' section: === 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 previous 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 previous 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. 3. Amend "These bugs can be marked as AcceptedBlocker by..." to "These bugs can be marked as accepted by..." https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 1. Add a bullet point to 'Review Proposed Blocker Bugs', after "After discussion, the leader will seek feedback on a proposed action...": #* If the group votes to accept the bug as a blocker, the leader should determine whether it is a normal blocker, 0-day blocker, or previous release blocker, and include the appropriate tag (AcceptedBlocker, Accepted0Day, or AcceptedPreviousRelease) in the proposal 2. Amend "add the text AcceptedBlocker (with that exact spelling and case)" to "add the text AcceptedBlocker, Accepted0Day or AcceptedPreviousRelease - as agreed - with that exact spelling and case" 3. Amend "...may quickly review the list of previously AcceptedBlocker bugs..." to "...may quickly review the list of previously accepted blocker bugs..." 4. Amend "...the secretary must add the text AcceptedBlocker or AcceptedFreezeException..." to "...the secretary must add the text AcceptedBlocker, Accepted0Day, AcceptedPreviousRelease or AcceptedFreezeException..." I believe that's all the policy/process documentation change that's necessary. We would have to adjust any code that looks for AcceptedBlocker also. I have a draft patch for blockerbugs that I'll polish up and submit to phab later in the week; does anyone know of any other code that would be affected? Comments, questions, suggestions etc. welcome! I'll go ahead and make these changes later this week if there's no problem with them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
