Proposal: "automatic blockers"

Adam Williamson awilliam at redhat.com
Thu Feb 21 02:23:17 UTC 2013


On Fri, 2013-02-15 at 18:34 -0800, Adam Williamson wrote:
> Hey, folks. So here's another proposal from an idea that was mentioned 
> during the F18 cycle.
> 
> There's a few types of blocker bug that are basically no-brainers; it 
> doesn't make a lot of sense to waste time in blocker meetings discussing 
> them, and more importantly, sometimes they show up and we want to 
> quickly accept them as blockers and get the fixes in, but we have to try 
> and track down three people to vote +1 before they can be accepted.
> 
> So I'm proposing we invent something called 'automatic blockers': a list 
> of bug types that can be declared AcceptedBlocker by any single person 
> in QA, releng or devel. That decision could of course be challenged and 
> changed if needed.

The initial feedback on this was broadly positive, but viking's first
response indicated it wasn't clear enough about how strict the
requirements are, and Andre suggested an additional type. Andre also
made the sensible suggestion that we could add a corresponding
'automatic freezeexception' procedure. Naturally, this would involve
adding a similar passage to
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process .
Here is a second draft of the proposed policy, which includes stronger
language about not making any other kind of bug 'automatic',
incorporates Andre's suggestion, and uses the term 'release-blocking
image' instead of 'required image' (this matches the term
'release-blocking desktop' used in the release criteria, and is rather
more accurate and clearer). It also adds a bit of text about each policy
in the _other_ policy (if you see what I mean), for what I hope are
obvious reasons.

************

Changes to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process:

== Automatic blockers ==

Certain types of bugs are considered ''automatic blockers''. These bugs
can be marked as AcceptedBlocker 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
[[QA:SOP_freeze_exception_bug_process#Automatic_freeze_exceptions|
automatic blocker 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 the DVD image (failures of
[[QA:Testcase_Mediakit_Repoclosure]])
* File conflicts between two packages on the DVD 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 -
"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]])

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].

Changes to
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process:

== Automatic freeze exceptions ==

Certain types of bugs are considered ''automatic freeze exception
bugs''. These bugs can be marked as AcceptedFreezeException 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 freeze exception'' policy and linking to this section of
this page. If anyone believes that a bug has been incorrectly marked as
AcceptedFreezeException 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 freeze exception bugs''. Note that where an
item on this list applies to non-release-blocking images, a
corresponding issue in a release-blocking image would likely be an
''automatic blocker'', under the corresponding
[[QA:SOP_blocker_bug_process#Automatic_blockers|automatic blocker
policy]].

* Bugs which entirely prevent the composition of one or more of the
non-release-blocking images expected to be built for a currently-pending
(pre-)release
* Incorrect checksums present on any of the non-release-blocking TC/RC
images (failures of [[QA:Testcase_Mediakit_ISO_Checksums]])
* Complete failure of any non-release-blocking TC/RC image to boot at
all - "DOA" image (conditional failure is not an automatic blocker)
* Any non-release-blocking Beta or Final TC/RC image exceeding its
target size (failures of [[QA:Testcase_Mediakit_ISO_Size]])

No other type of bug can be considered an ''automatic freeze exception
bug'' under any circumstance. In particular, "I think it is obviously a
freeze exception bug" 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].

*****************
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list