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