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&am...
> 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