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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
