Using flags for blocker bug tracking

[Kamil Paral]

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

Can we somehow tell Bugzilla to switch all our flags to ? (or remove them completely) if Version changes? So that a rejected blocker for F18 doesn't become a rejected blocker for F19, when somebody changes Version? Or accepted freeze exception for F18 doesn't became an accepted freeze exception for F19? We can check these things manually, yes, but it's tiresome.

But in all cases, the history gets distorted. By changing Version from 18 to 19, we no longer can query for that bug in F18. Which means are statistics won't be fully true. Do we care?

We can avoid the history distortion if we do a mass-change to all accepted/rejected blockers/freeze-exceptions after the release is over and add a special Whiteboard field for them. The statistics would be then created using the whiteboard fields rather than flags. But that's an extra work and an extra complexity. It still doesn't solve the problem for Version changes.

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

This seems as a better approach, but who gets to create those flags? Can you be given the permissions to do that? Or do we need to contact Bugzilla administrators every time? What's their response time, can we rely on that? I also don't know what the performance implications are of having so many flags.

They will have to be versioned, so back from AcceptedBlocker to f19-blocker. But I don't see it as a major problem.

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

Who can set the flags, anyone with Bugzilla account or some special permissions are needed, like for Blocks field?

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

Actually I thought about this just a short time ago when looking at Tim's new proposal of blocker submission form. We could manage all that information outside of Bugzilla. What does it bring us?

1. faster, better interface (probably)
2. less BZ spam

but also

3. lots of extra work to duplicate basic functionality - the tracker app has to be able to manage the list (add/edit/remove items), do authentication/authorization (not everyone can do everything), offer notifications, and many more. We are given that automatically by using Bugzilla.
4. obligation to maintain it - if something goes wrong with our current tracker app, we can fall back to Bugzilla just fine, it's just a bit less convenient. If we move the data into the app, we depend on it completely.

I think, for the time being, it's just better to use Bugzilla as a backend and create a pretty UI for it, as we currently have. We're quite scarce on human resources even now, I wouldn't want to put more maintenance burden on us. The benefits of leaving Bugzilla doesn't seem to outweigh the drawbacks.