On Mon, 2009-09-14 at 08:23 -0400, Paul W. Frields wrote:
I wanted to suggest https://bugzilla.redhat.com/show_bug.cgi?id=518880 as a candidate for blocker status, because it's a regression in a well-publicized feature. (The maintainers are already aware of the problem and working on it, I'd just like to make sure it's not lost in the shuffle.)
That criterion is worth considering generally for blocker status. But maybe it needs some refinement?
We don't really have hard and fast criteria for blockers. This is for two reasons: a) we're too lazy to write any, and b) it's really hard. b) obviously has significant implications for a). ;)
less flippantly, it's almost impossible to quantify blocker-ness in terms flexible enough to cover all cases, but rigid enough to be of any actual use in objective evaluation (as opposed to just coming down to a subjective judgment call, which is what we currently use).
We have a fairly solid definition for *Alpha* blockers - only 'high' or 'urgent' severity bugs in critical path components - but even that requires occasional exceptions, and the higher standard required of Beta and final releases makes it harder to define blocker-ness.
So, short story, right now it's a judgment call. I'd certainly judge that this bug is a _final release_ blocker. Whether it's a beta blocker is a trickier call. We'll make sure to cover it in the meeting on Friday to see what everyone thinks.
The two main ways to propose something as a blocker: show up to the meeting and raise it, or simply set it as one (as someone's done for this bug already - it's been set as a final release blocker at present) and it'll automatically get looked at during the meeting. If the consensus at the meeting is that it isn't a blocker, it'll be dropped (with an explanation).