On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote: > I've talked about this before, but maybe the F26 cycle is time to make > it happen. Right now, we have only one way of saying "this bug is > important to the project as a whole; could we please get resources > focused on it?" — and that way is to stop the whole vehicle until > someone does something about it. This has always been kind of > problematic, even though it has served well enough so far... but as we > move to more deliverables and add things with different lifecycles, I > think we need something else. > > We have the Accepted Blockers > <https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist> > list. The process is nicely documented at > <https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process>; please > read that if you're not familiar. > > I propose we create a parallel "Critical Issues" list, using basically > the same procedures. Issues eligible for this status would be those > which do not necessarily fail a release criterion but which have > critical impact on a Fedora Edition or on a council-approved Fedora > Objective. We used to have exactly this, up until Fedora 14. We had 'Target' trackers as well as 'Blocker' trackers. Fedora 14 was in fact a rather special release as it had all three concepts: 'blocker', 'freeze exception' (though we called these something else at the time) and 'target'. (F13 had a 'Target' tracker but no freeze exception trackers, F15 had blocker and freeze exception trackers but no 'Target' tracker). Here's the F14 Beta blocker tracker: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=611991 the Beta freeze exception tracker: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=634253 and the 'Target' tracker (we never split these by milestone): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=538278 The Target trackers were discontinued, so far as I recall, because no- one ever really took a blind bit of notice of them. People would throw bugs onto the list and then...nothing much would happen. It was just kind of a wishlist and (IIRC) very few packagers even looked at it, and even those involved in release wrangling had enough on their plates just dealing with the blocker list. At that point the blocker process was rather less defined than it is now, and there was absolutely no kind of 'process' around the Target tracker - it just got created, there was no kind of process that made it anyone's job to actually care about the bugs on the list - so it's possible that this idea could fly better with some kind of process around it. But I think it's worth noting we had this before and explicitly stopped doing it because it was kinda pointless. > We could either implement this by extending the existing blocker bug > process — adding a new tracker bug, add a new category in the > blockerbug app, and review candidate issues at the normal blocker > review meetings. Or, it could be done in parallel, with a > separately-configured instance of the blockerbug app and with review > in a separate meeting called as needed (or maybe just FESCo?) > > As with the existing Blocker or Freeze Exception levels, we could also > introduce a second tier "Important Issues", which could have a wider > net than the rules for "Critical Issues". I'm not sure about that. > > In any case, what do you all think? Blocker review is a rather resource-intensive process, where the resource involved are of the squishy human kind. I'm not sure anyone would be super-thrilled about spending several *extra* hours per week having bunfights about whether an issue is 'critical' or 'important'. I think if we're gonna go with this it might make sense to use a rather lighter process than the blocker review process, though I don't have a specific proposal for how that could look at this point in time. If it would mainly be used by the FPL and FPM, perhaps it could simply be the rule that they got to decide what bugs went on it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
