Review of Fedora 18 Release Criteria

[Adam Williamson]

On Wed, 2012-10-10 at 15:35 -0600, Chris Murphy wrote:
> Two suggestions for possible changes in blocker bug procedures:
> 
> 1. I think more burden should be placed on he who proposes a bug as a blocker.
> a.) what release criterion applies
> b.) what workarounds are there
> c.) what are the contra-arguments to blocking
> 
> 2. The above information would be useful in scanning blocker bugs, and triaging their review. I'm not clear on the method for ordering the review, but it would probably be helpful getting non-QA participation if say, anaconda bugs were being reviewed all at once and in triaged order.
> 
> The Wednesday scheduled blocker meeting should not, in my view, be "dicking around" with reviewers trying to infer why a bug was proposed as blocker. I'd relegate such bugs to last call or see those bumped to an unscheduled day.
> 
> Something like that.

I've always liked having a low bar to proposing blockers as it's like
the justice system - it's much worse to let a single correct blocker bug
go unproposed than to have one hundred incorrect blocker bugs proposed
and rejected :)

but obviously it'd save us time if we didn't have to do so much
spadework on vague proposals at the meeting, yeah.

Perhaps the way to square that circle is to have more of a concerted
effort to improve the proposals *before* the meetings. This has been
proposed a few times but in the end no-one's stepped up and starting
doing it. It'd really just be a triage effort: go through the list of
proposed blockers, and for ones where the impact of the bug is vague
and/or the grounds for blocker status are neither really obvious nor
provided in the bug, ask for more details.

I think that way we could make the meetings more efficient without
running the risk of missing proposals.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net