On Thu, 2013-01-24 at 06:50 -0500, Kamil Paral wrote:
> 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.
Good thinking. I hadn't considered these wrinkles, and you're absolutely
right. Some of them actually apply to our current method too, but not as
badly. Not much to add here except, yeah, these are legitimate concerns
and they make me like this model less.
> 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.
So I should've made this clearer, but I checked in with the current RH
BZ maintenance team ahead of time, and they didn't seem to be fazed by
this idea: we would have to ask them to create the flags, but they say
the turnaround time on that can be very fast and they didn't seem to
hate the possibility of creating six new flags every release and
archiving the old ones, so I'm guessing it's not going to cause a
performance problem.
They will have to be versioned, so back from AcceptedBlocker to
f19-blocker. But I don't see it as a major problem.
Yes, obviously in this plan the flags would always be versioned.
> 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 can be done either way, and the permissions for setting ? can be made
different from the permissions for setting + or -. It would seem obvious
that we should let anyone set ?. We could choose to restrict the
permissions for setting + or - to a certain group, but that might be
overcomplicating things - we haven't had any problems with abuse of the
current process, I don't think.
> 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.
I didn't mean for this thread to turn into a detailed discussion of this
possibility, I was more just including it to make people aware that the
flags thing might wind up being just a stopgap. I think Tim will make a
detailed proposal of his idea when he's ready. But of course, if we were
to definitely reject that plan, it may change the equation with regards
to using flags.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net