Re: GNOME2 Bug Triage guidelines
- From: James Henstridge <james daa com au>
- To: Luis Villa <louie ximian com>
- Cc: gnome-hackers gnome org, gnome2 release team <gnome2-release-team gnome org>
- Subject: Re: GNOME2 Bug Triage guidelines
- Date: Mon, 21 Jan 2002 20:08:13 +0800
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/
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]