Using flags for blocker bug tracking

[Adam Williamson]

On Thu, 2013-01-24 at 10:17 -0700, Tim Flink wrote:

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

Sure, let's call that 3). This is essentially using flags to replace the
Whiteboard field, but continuing to use tracker bugs: it's a much more
moderate option. 1) and 2) entirely replace the current use of both
tracker bugs and the whiteboard field.

I'm not sure it would make sense to use two 'accepted' and 'rejected'
flags in this way, it seems more sensible to me just to have a flag
'blocker' for blockers and 'freezeexception' for freeze exceptions, and
set that flag's state depending on the decision made in the meeting.
Flags aren't required to go ? before they go + or -. We could just
consider bugs blocking the trackers but with no flag status as
'proposed', much like at present, then use the flag status to indicate
acceptance or rejection, again much as we do with the WB.

To me this is very similar to using keywords instead of the WB, really -
it has the same advantages and disadvantages compared to the WB field,
which is that it's somewhat more programmatic so it eliminates the
possibility of data entry errors, and it may be slightly more prominent
and hence obvious than use of the WB field, but it requires us to ask
the RH BZ team to do something for us. Either this or the keyword
approach might be worth trying to get done for F19, though, since we
seem to have a somewhat more responsive BZ maintenance team ATM, and
neither change requires anything *ongoing* from them.

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

Yeah, this is definitely post-F19 stuff.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net