On Wed, 23 Jan 2013 18:47:44 -0800 Adam Williamson <awilliam@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
