Release-critical bug process?

[Adam Williamson]

On Wed, 2009-02-11 at 11:21 -0800, Jesse Keating wrote:

> > people who would like input into that process (man, I shouldn't have
> > thrown away that fridge magnet or I'd know the terminology ;>) - need to
> > decide on a process that will actually be honored by both sides.
> 
> You're thinking of RACI, Responsible, Accountable, Consulted, and
> Informed.

That was it.


> What's happened in the past is more like this:
> 
> Zappers add /potential/ blockers to a blocker list, and
> releng/qa/sigs/etc.. review the issues on the blocker list and determine
> if we really would delay the release for the issue, and move it
> accordingly.  That process is somewhat opaque and often happens either
> over a phone call (Fedora Talk) or IRC meetings, were we hijack people's
> time to actually look at the bugs and make the call.  Each special
> interest area (SIG) makes the call for the bugs that effect their area.
> We don't have the best participation here, but we're trying to grow it.

It just doesn't seem like the best way of organizing things - that way
no-one really has ownership of the process, I suspect that it becomes
something of a mess and there's lots of heat without light? It also
sounds like it doesn't necessarily take on board much feedback from
users. I honestly think it'd work better if a group - as I said, I think
bugzappers is the best candidate - had ownership of the blocker bugs
process. Of course, they should be very receptive to input from the SIGs
and developers, and there would at a practical level be an ultimate
override in the hands of the guys who actually do the releases.

Sorry if I'm way off base on this, just trying to provide a perspective.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net