Re: GNOME2 Bug Triage guidelines

[Luis Villa <louie ximian com>]

On Mon, 2002-01-21 at 07:08, James Henstridge wrote:
> Luis Villa wrot
> >(1) All G2 bugs need to be marked as such. After some discussion, we're
> >going to use target milestones for this. It's imperfect, but so are
> >keywords. Later tonight or tomorrow, every product in bugzilla will get 
> >target milestones corresponding to GNOME2 Beta, RC1, Final, and
> >'post-GNOME2' [G2Beta, G2RC1, G2.0, G2.x]. If a bug's target milestone
> >is set to one of these four, it is a bug in GNOME 2. The first three are
> >GNOME 2 bugs that ought to be fixed for the actual 2.0 release; the
> >closer we get to 2.0 the tougher it'll be to mark a bug G2.0. The G2.x
> >milestone will keep track of those bugs that are in GNOME2 but not
> >fixable or not prioritized for the 2.0 release. A fair number of
> >projects [mainly gnome-core, gnome-utils, and gnome-applets] already
> >have 2.0 milestones. For those products that already have and use 2.0
> >milestones, I'll convert those into G2.0 milestones, so that we can have
> >consistency across the bugzilla.
> >
> I would strongly recommend using keywords for these target nominations.
> 
> In Mozilla's bugzilla, the milestone field in a bug is treated as the 
> property of the bug owner, and setting the milestone on someone else's 
> bug is not done.  They have a separate set of keywords corresponding to 
> future mozilla releases, which are set on bugs by the release team for 
> bugs nominated for a particular release.  The bug owner then makes the 
> final decision for what the milestone is set to (of course if someone is 
> being paid to work on mozilla, their manager might tell them when the 
> bug should be fixed by).

b.m.o. have actually (mainly) moved away from the keyword-based model
for a number of reasons, most of which aren't relevant to us. 

I prefer milestones for a couple of reasons. The big one is that they're
basically unused in b.g.o.- only a handful of platforms use them; all of
the ones who do (pretty much without exception) have 2.0 milestones.
Now, of course, Owen points out that his 2.0 is not my 2.0. AFAICT,
that's the only truly relevant objection, because basically no one else
who is using 2.0 milestones (against, AFAICS) means something other than
gnome2.0.

My other reasons for my preference are sort of scattered, but all
relevant. They're listed on every bug page, making it easier to deal
with them- no 'oh, I forgot to add the keyword', which makes things much
more consistent across the bugzilla. Even with me working on it
full-time, that kind of thing /will/ make a difference. Since it's a
dropdown, it also encourages choices when one has to change things- it's
much easier to just delete a keyword and lose all the data (which I'm
sure will happen) than to select 'oh, it's not 2.0... therefore it's
2.x', which allows us to keep information much more easily. Again, not a
problem for individual projects, but if you're trying to keep things
sane across 90+ products, it's important.

> 1) some packages are already using milestones to manage their releases 
> (such as gtk+).  If you go and change the milestone, the maintainers 
> will most likely not see the bugs when they query for the bugs they need 
> to fix for the 2.0 release.

I plan to work with the maintainers to resolve this issue; specifically,
it's very easy to just s/2.0/GNOME2.0/ to minimize confusion. Or so I
thought until I saw Owen's email; I'm still fairly sure this is true for
everyone who isn't gtk but I may well be wrong.

> 2) a bug can only have one target milestone, but any number of keywords. 
>  If a bug has the milestone set already, you are removing some of the 
> information set by the bug owner.  If keywords are being used, 
> nominating a bug for a 2.0 release target simply adds information.

If programs used milestones extensively, this would be a problem. Of the
programs in the gnome core, my initial scan of things showed that
exactly one (glib) had more than one 2.0 related keyword, and that other
one (2.0 API Freeze) has already passed. So, while this is a
hypothetical problem, no product actually using b.g.o. milestones will
be affected. All told, as of late last week, only 6 core products use
keywords at all; they're either 2.0, 2.0.x, or 2.0 API Freeze, all of
which map cleanly to the proposed priorities.
 
> 3) the 2.0 milestones added to some bugzilla products may not make sense 
> w.r.t. the existing milestones on the product.  Setting a keyword on the 
> bug, and letting the bug owner set the milestone appropriately.

As per the above, there are no cases in the gnome core [from what I can
tell] where milestones are already used in b.g.o. and where 2.0
milestones won't make sense. Owen again proves the exception to the rule
here.

> I understand that it is useful from a release coordination point of view 
> to be able to query for a particular milestone for all products (which 
> is why you might want standard milestone names), but it should be just 
> as easy to query by keyword to do this.  In fact, using keywords here 
> fits into the bugzilla architecture much better (milestone names are per 
> product, while keywords are system wide).

As you may have noticed this morning, it's fairly easy to write a script
to make milestones global, with a touch of SQL. :)

> It would be great if you would consider using keywords for bug nominations.

So, I still prefer milestones, because they interfere minimally with all
but one product, and they will encourage greater consistency than
keywords can provide- a consistency which is important for a gnome2 that
doesn't suck. But GNOME2 bug work cannot use something that isn't
global.* So I'm stuck between a rock and gtk+, as well as any other
projects that might (for good or bad reasons; Owen's seem perfectly
valid) feel that these milestones are not usable for them.

I guess this means keywords, and soon, but I'm going to leave the issue
open for today while I work on other stuff and see if anyone else has a
workable compromise.

Luis

*cannot is strong. We /can/ choose to continue to each be our own
fragmented little empires, and allow GNOME as a cohesive project to
continue to wither. I'd prefer that my own work not contribute to that.