This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Use of Bugzilla fields
- From: Mark Mitchell <mark at codesourcery dot com>
- To: gcc mailing list <gcc at gcc dot gnu dot org>
- Cc: Daniel Berlin <dberlin at dberlin dot org>
- Date: Sun, 30 Oct 2005 13:42:04 -0800
- Subject: Use of Bugzilla fields
[Danny, see below for a request.]
In my review of open PRs against the 4.1 branch, I'm going to adopt a
new convention.
Until now, when I've decided something is not important enough to
require fixing for a particular release, I unset the target milestone.
That's confusing because it might seem to mean that I'm saying the bug
*can't* be fixed for a particular release, which isn't true.
So, I'm going to adopt a new convention in these cases. In particular,
I'm going to leave the target milestone alone, but set the priority field.
P1 bugs will be bugs I think absolutely must be fixed before the next
release; releasing with this bug would be diastrous.
I'd like to use P2 to indicate that I've review the bug, and that it
does not merit P1 status, but is important.
So, Danny, is there any chance we could make it impossible for
submitters to set this value and make P3 the default instead of P2?
Severity is supposed to be "if this problem affects you, how bad is
it?"; submitters can reasonably answer that. However, priority should
be "in the grand scheme of things, how urgent is it that this shoudl be
fixed?"; only we can decide that.
P3 would then be the default, and would indicate that I've not yet
reviewed the bug.
P4 bugs will be ones I consider too unimportant to block the current
release.
P5 bugs will be ones I consider too unimportant to block *any* future
release. I'm going to add links to the main web page to query for the
regressions I think are important enough to block a release.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304