Re: GNOME2 Bug Triage guidelines

[James Henstridge <james daa com au>]

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

In the context of gnome, there are a number of reasons to follow this 
pattern rather than the release team setting milestones:

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.

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.

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.

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

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

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/