On Wed, 18 Jun 2003, Richard Earnshaw wrote:

> > The whole idea of having two dimensions to the severity is what's
> > really wacky. A single scale with a few more slots in it would be
> > nice. It would also give us a chance to review the old ones, as the
> > filing use isn't necessarily the best one to assess the priority.
>
> We don't have two dimensions to severity.  We have one dimension of
> severity and one of importance.  Be careful not to confuse the two, they
> are very different.
>
> We should be using priorities to govern what must be fixed before a
> release is made, not necessarily severity.

> PS  It's often true that a critical bug is likely to be high priority, and
> a non-critical one of low priority, but that's not hard and fast.  Indeed
> if we triaged bugs properly as they came in, we could assess their
> priority to the project and ensure that important (to us) bugs were fixed
> before a release rather than languishing in the database untouched.

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.

Frederick