> On Wed, 18 Jun 2003, Richard Earnshaw wrote:
> 
> > > Well then, they're listed wrong on the web page. They're sorted by
> > > severity first, then by priority. I suggest that the "priority" should
> > > be the "severity", nothing more or less -- so that "security-critical"
> > > bugs get placed before "build-critical" bugs, which get placed before
> > > "serious" bugs, which get placed before "feature-requests", which get
> > > placed before "doc" bugs -- without exception.
> >
> > We already have a security category for security related issues, so I
> > don't think that should skew the sorting. As for the rest of your
> > proposed order, then that is a matter of personal taste: Do you really
> > think that adding new features is more important than fixing bugs in the
> > existing documentation?
> 
> Maybe not. Given that the priority is subordinate to the severity, we
> really can't use "priority" as you've suggested, either. How about if
> all new bugs are priority "high", all assigned bugs are changed to
> priority "medium", and all suspended (or pending? or feedback?) bugs
> are changed to priority "low"?
> 

Why are you trying to map priority onto another feature that already 
exists?  It's really quite simple:

Severity	is the impact on the user
Category	class of problem (port, security, general kernel, library etc)
Priority	How important is resolving this bug to NetBSD developers
State		Where the "bug" has reached in its processing
Class		The type of report (sw-bug, doc-bug, change-request, etc)

There's absolutely no reason why there can't (in theory) be a critical 
sw-bug with low priority (eg, some old hardware that NetBSD now considers 
deprecated) or a non-critical change-request with high priority (eg, a 
suggestion that's really liked by developers, but involves an API issue 
that must be resolved before the next release goes out).

Just because a developer takes ownership of a problem doesn't change its 
priority, nor does wanting more information from the submitter.

> > Part of the problem with gnats is that its report generation is fairly
> > primitive; having started use bugzilla on GCC recently, the difference is
> > clearly vast.
> 
> I'm not that impressed with bugzilla. I find it difficult to get a
> list of *all* the bugs, and then once you're in a bug, it's really
> difficult to see the patches.

http://gcc.gnu.org/bugzilla/query.cgi

Just click on the submit button and you get a complete list of all open 
bugs.  Once in a bug, just click on the attachment and you can see the 
patch in your browser, or download it.

If all the open bugs isn't good enough, then adding the closed ones as 
well is completely trivial.

Oh, and since it's based on a proper database it does it near 
instantaneously, instead of over a cup of tea.

R.