On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote: > Hi, everyone. So we partly used the proposed new nice-to-have bug > tracking system during the F14 Beta process, and it seemed to go well. > In a quick burst of airport productivity, I've quickly written up a > bunch of proposed new wiki pages and modifications to existing ones to > document the nice-to-have process (and, incidentally, extend > documentation of the blocker process, since we don't seem to have much > of it beyond the blocker meeting SOP right now). All the pages can be > found here: > > https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts Thanks for providing draft wiki edits with the proposal. I've made a few _minor_ tweaks to the wiki pages. > it should be pretty obvious which are new and which are modifications of > existing pages. I hope this is mostly straightforward and > non-controversial. > > A quick five-minute summary is that we will now have (in fact, we > already do) trackers for nice-to-have bugs for Alpha, Beta and Final > releases as well as trackers for blocker bugs. Bugs on these NTH lists > will be given priority after blocker bugs for QA, devel and releng work > for releases. Fixes for these bugs - and *only* these bugs, if a fix is > to be taken through a freeze, there must be a matching accepted NTH bug > - will be taken through release freezes. Proposing, reviewing and > monitoring NTH bugs will work exactly as it does for blocker bugs, and > mostly happen in the blocker meetings, but of course after consideration > of the blocker lists. I like the idea of formalizing the 'nice-to-have' process. I recall tension during the F-13-RC phase regarding the decision making process that allowed a selection of non-Blocker fixes into the release. I hope that this process helps clarify the acceptable exceptions to the blocker process. > 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. 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)? [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? 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, James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
