On 02/16/2013 02:34 AM, 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 specific proposal is to add this section to
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process , right
under "Reviewing blocker bugs":
************
== 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.
The following types of bug are considered ''automatic blockers'':
* Bugs which entirely prevent the composition of one or more of the
images required to be built for a currently-pending (pre-)release
* Incorrect checksums present on any of the required 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 required TC/RC image to boot at all - "DOA"
image (conditional failure is not an automatic blocker)
************
Any thoughts on the general idea, or on the specific list of bug types
I came up with - any more to add to the list, or remove from it? I
don't want to make the list _too_ big, and it shouldn't include any
type of bug that could possibly _not_ be a blocker, we want it to be
only the completely, 100%, screaming obvious slam-dunks. The last
entry is a bit of a 'possible' in my mind, there's an argument for not
including it, as people might interpret it too widely. It's meant to
cover only the case where we build a TC/RC and it's utterly DOA: the
image just flat out fails to boot, for everyone, no matter what the
hardware or configuration, it's just dead.
The problem being that what is an automatic blocker to me is not an
automatic blocker to you.
Case in point from last release cycle the regression I faced with radeon
driver
JBG
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
