Non-media blockers: proposed wiki revisions
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