Release-critical bug process?

[James Laska]

On Wed, 2009-02-11 at 09:33 -0800, Jesse Keating wrote:
> On Wed, 2009-02-11 at 09:33 -0800, John Poelstra wrote:
> > Jesse Keating said the following on 02/11/2009 09:21 AM Pacific Time:
> > > On Wed, 2009-02-11 at 09:18 -0800, John Poelstra wrote:
> > >>  Nothing is worse than spending several hours triaging bugs to a blocker 
> > >> list only to find out that the blocker list isn't being used or that the 
> > >> release has been deemed "done enough" and has gone to the mirrors.  I 
> > >> know every bit helps, but it is still demoralizing.
> > > 
> > > While I agree to an extent, just because we chose not to fix the bug
> > > before the release, doesn't mean that the bug shouldn't be fixed.  The
> > > efforts put in won't be in vain at all, it just may take a little bit
> > > more time before the return on investment.
> > > 
> > > 
> > 
> > My core issue is not knowing a decision has been made about the quality 
> > of a release and how that decision was arrived at.  We talk a lot about 
> > transparency in decision making in Fedora.  I think it applies here too :)
> > 
> > John
> 
> 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.

Thanks,
James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20090211/02f55d99/attachment.bin