Release-critical bug process?

[Adam Williamson]

On Wed, 2009-02-11 at 17:43 +0000, James Laska wrote:

> > I'll also note that being head-down working on a bug and missing an IRC
> > conversation is not that far off from being head-down working on a bug
> > and missing an email that went by (:
> 
> Agreed to both.  This hits the nail on the head for me.  I'd like to
> spend some time outlining the inputs and outputs for Fedora QA during
> the release process.  
> 
> What is expected of us, when is it expected?  How will we communicate
> status, where will these communications occur?  When do we start
> testing, where do we get our bits from, how do we know we're done?  What
> happens when the __it hits the fan?
> 
> I don't think we should be pedantic about documenting the process ...
> but making an effort here will pay off for all involved.  Making the
> process more transparent should invite outside contributions+input and I
> guarantee will help identify soft spots where tooling or process changes
> could simplify things.

Reading this conversation on the list and various other places it's been
going on, my input would be that the basic problem is there's a process
which is not really honored here, creating friction on both sides.

The BugZappers group is carefully maintaining a list of blocker bugs for
each pre-release, as well as the final release. This list is then not
really being honored. The fact that they don't always even get an
explanation why not may be aggravating, but it's not really the
important thing here.

It seems to me that what really needs to happen is we - the people who
actually have the power to decide when a release goes out, and the
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.

This could be as simple as just saying, well, we don't really want to
bother with formal blocker lists for pre-releases (as is, practically
speaking, the case at present). Pre-releases aren't stable. They're
allowed to be broken. An informal "are there any real howlers? No? Let's
go, then!" between a couple of people is enough. If everyone's happy
with that, then that's fine, and the BugZappers can stop wasting time
constructing blocker lists for pre-releases.

Alternatively, we decide that we *do* want blocker lists for
pre-releases, in which case those making the pre-releases have to honor
them, which means either waiting until all the bugs on them are resolved
or giving a proper explanation of why they're releasing without this
happening. And we also specify who gets input into the blocker list. I
would say that should be managed by the BugZappers, as they should be
the group with the greatest ability to judge what issues are truly
critical.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net