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