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
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
existing pages. I hope this is mostly straightforward and
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
In practice this is a formalization of existing procedure - until
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
* The fix would have to be packaged and available in bodhi
* 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
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) . 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
Some releng SOP pages may require minor updates, I figured I'd
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?)
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?
up for some
additional reading, I'll reply later with any additional comments.