Using flags for blocker bug tracking

Adam Williamson awilliam at redhat.com
Thu Jan 24 02:47:44 UTC 2013


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



More information about the test mailing list