Review request: Nice-to-have bug process documentation proposal

Adam Williamson awilliam at redhat.com
Mon Sep 27 22:44:25 UTC 2010


On Fri, 2010-09-24 at 16:22 -0400, James Laska wrote:

> > In practice this is a formalization of existing procedure - until F14
> > Beta, QA and releng did much the same process but entirely informally,
> > we just kept lists of bugs we'd take fixes for either in our heads or in
> > the RC creation trac tickets. This process is meant to be more robust,
> > documented and discoverable.
> 
> Perhaps the pending rel-eng SOP documents would cover this, but I'm
> unclear how FXX-accepted bugs are treated during at compose time.  For
> our current Blocker bug process, it's established that if the
> appropriate blocker bug list is not empty, we can't compose.  With
> non-blocker nice-to-have (NTH) bugs, how would that fix get into a
> compose?
> 
> Guessing ...
>       * The fix would have to be packaged and available in bodhi
>         updates-testing
>       * The bodhi update has received the required karma
>       * The accepted bug is in VERIFIED state?
> 
> To summarize, what instructions can we provide maintainers with so they
> can be confident an tested, packaged and approved nice-to-have fix will
> be pulled into any (re)compose?  Perhaps, more of a question for the
> release-engineering team.

So far, we haven't been that strict; the process has been that I've
listed any builds currently available in Koji which address nth issues
in the RC compose request ticket, and then it's been up to rel-eng to
take them or not. I agree we should nail this down a little better, and
your list seems reasonable (though I'd probably say it's not necessary
that the build be *available* in updates-testing, just that it have been
*submitted* there; waiting for an updates-testing compose is an
arbitrary limitation). Indeed this is probably something to co-ordinate
with releng's SOPs on.

> Different topic ...
> 
> In the days of using *only* Blocker bugs, it's now somewhat confusing to
> look at the F14Beta-accepted tracker, after we started mirroring
> F14Beta, and see 12 open bugs (some trackers) [1].  I don't think this
> is a bad thing, but perhaps another item to manage based on the result
> of the go/no-go meeting ... move any pending FXX-accepted bugs into the
> next milestone (so open FXXBeta-accepted bugs would move to
> FXX-accepted)?

Yes, I meant to include that and forgot about it. Indeed this should be
the process.

> [1]
> https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-accepted&hide_resolved=1
> 
> > Some releng SOP pages may require minor updates, I figured I'd leave
> > that to releng. The process for creating blocker trackers should also be
> > updated to cover creating NTH trackers (I couldn't find that; poelcat,
> > where is it?)
> 
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
> 
> 
> I assume "User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft" is
> intended to replace "QA:SOP_Blocker_Bug_Meeting", and not define an
> additional blocker review meeting?

Yes. I considered creating a separate page detailing a 'nice-to-have
review meeting' and noting that in practice it could be combined with
the blocker meeting, but that just felt like over-engineering.

> I've queued
> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some additional reading, I'll reply later with any additional comments.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net



More information about the devel mailing list