Nice-to-have bug trackers

[Adam Williamson]

Hi, everyone. I'd just like to point up a new process we just put in
place: tracking nice-to-have bugs for pre- and final releases.

Sorry not to have proposed this on the list, but I wanted to try and get
it done for the Beta so I just went ahead and put it in. The idea is to
track bugs that aren't blocking a release, but for which we'll take the
fix through the freeze if it's available before we do a build.

We've always had such bugs, but we haven't had any kind of mechanism for
tracking them, so I figured anything's better than nothing. =) We should
probably have a full system for proposing such bugs and reviewing them
and marking them as accepted and criteria for deciding, just as we do
for blockers, but for now all I wanted was somewhere we could actually
*track* the bugs, so it's not just us and releng trying to keep them in
our heads. So with help from Jesse, James and John, we came up with this
system.

There are now bugs named F14Beta-accepted and F14-accepted:

https://bugzilla.redhat.com/show_bug.cgi?id=F14Beta-accepted
https://bugzilla.redhat.com/show_bug.cgi?id=F14-accepted

Bugs for which we'll take fixes up to the final build, but which don't
block the release - 'nice-to-have' bugs - will block the appropriate one
of these (obviously for F15 we'll have F15Alpha-accepted,
F15Beta-accepted, and F15-accepted, and so on for future releases).
F14Blocker blocks F14-accepted and F14Beta block F14Beta-accepted. So if
you want to see all the bugs we'll take fixes for at a glance you can
look at the -accepted bugs, and if you just want to see blockers you can
look at the blocker bugs as usual. The idea is that when spinning
releases, releng can see at a glance the list of bugs we'll take fixes
for, see if fixes are available, and go ahead and pull them if they are
- we won't be trying to figure out in IRC or a trac ticket or whatever
what builds we want to pull and what we don't.

Right now that's basically all we have: it's simply a tracking system.
We've thrown a few bugs on there for F14 Beta. For final, it'd be nice
to have a process for adding and reviewing bugs, though writing criteria
for NTH bugs may be hard: we may have to go with guiding principles
rather than criteria.

My first thought for the process is we can basically mirror the blocker
process - you throw a bug onto the list to have it considered, then we
review them and decide whether to accept them in the blocker meetings,
using a whiteboard tag. What does everyone think about this? Any
concerns, or alternative proposals or improvements? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net