Hey, folks. So I just wanted to kick off a discussion on the merits or otherwise of using flags for tracking blocker bugs. If you're not aware how Bugzilla flags work, http://www.bugzilla.org/docs/4.4/en/html/flags-overview.html gives an overview. A flag is just a named attribute of the bug with four states: unset, ?, + and -. This obviously lends itself nicely to blocker tracking: setting a bug to ? would 'propose' it as a blocker, setting it to + would 'accept' it as a blocker, and setting it to - would 'reject' it as a blocker. The main benefit of flags as I see them: 1) 'Proposed' state is much clearer 2) Removes reliance on whiteboard/keywords field 3) May simplify code needed in tools that parse blocker state (e.g. blocker bug webapp) There are two ways we could do flags that I can see: 1) Create a set of six unversioned flags, using the name format we came up with for the blocker aliases (AlphaBlocker, AlphaFreezeException, BetaBlocker...), and use the Version: field to track the version being blocked (so a bug with Version: 18 and AlphaBlocker+ is an accepted blocker for F18 Alpha, a bug with Version: 19 and BetaFreezeException? is a proposed blocker for F19 Beta, etc) 2) Create six versioned flags for each release, one release ahead of time (as we do now for blocker bugs); mark flags for finished releases as 'inactive' (this means they don't appear in the BZ UI but can still be searched on, which would be exactly what we'd want) 1) is a bit simpler and less work on the BZ team (and stress on the database), but relies on the Version: field for blocker/FE bugs being handled carefully; sometimes it gets changed on bugs, and sometimes inappropriately. So that could be a danger. 2) is safer but does require us to go and get flags created for every Fedora release, and leave a bunch of inactive flags in the archive. Drawbacks of flags: 1) It's probably a slightly less well-understood mechanism than tracker bugs 2) A change from the process we've used for a long time - will need some rework of documentation and education of devel, QA, releng 3) Bugzilla doesn't draw you a 'nice' tree view of bugs with a given flag set like it does for bugs blocking a given tracker (though this isn't a significant factor really now we have the blocker webapp) I don't have a specific recommendation, really I just wanted to kick off a discussion and see how people feel about the possibility, and whether anyone has anything to add to the pro/minus columns. This would likely be F20 stuff if we were going to go for it. It's also worth considering the possibility that blocker tracking could be moved out of BZ itself and into the blocker webapp; this has several advantages, like better integration with the webapp, reducing BZ spam, and giving us a mechanism for asynchronous review of blockers without BZ spam. So that may possibly be the best option, but it depends on someone (hi Tim!) having time to write the code. Still, it's one of Tim's long-term plans, and people may feel it's best to stick with tracker bugs until we're ready to go to that plan instead of using flags as an intermediate step. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
