Using flags for blocker bug tracking

[Tim Flink]

On Wed, 23 Jan 2013 18:47:44 -0800
Adam Williamson <awilliam at redhat.com> wrote:

> 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)

I would add:
3) create 2 flags: accepted and rejected. These could be used with the
tracking bugs to indicate state:

  Proposed Alpha Blocker:
    blocks fXXAlphaBlocker
  Accepted Alpha Blocker:
    blocks fXXAlphaBlocker
    accepted+
  Rejected Alpha Blocker
    does not block fXXAlphaBlocker
    rejected+

Of course, I could just be completely misunderstanding how flags work
but I see this as not a huge change to our current processes and not a
huge change request to the bugzilla devs.

<snip>

> 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.

Yeah, I mentioned this in the proposal UI thread. I just finished a
_very_ initial evaluation of what I had planned and while I think it
could work, I have concerns about whether the amount of work required
would be worth the benefit we would see (similar to Kamil's concerns).

Either way, I don't see it happening for F19 unless the release is
pushed out much farther than I suspect it will.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20130124/ca648286/attachment.sig>