On Tue, 17 Jun 2003, Matthias Scheler wrote:

> On Tue, Jun 17, 2003 at 09:48:30PM +0200, Matthias Scheler wrote:
> > > send-pr(1):
> > >
> > >     critical
> > >            The product, component  or  concept  is  completely
> > >            non-operational  or some essential functionality is
> > >            missing (e.g. kernel panic or program core  dumps).
> > >            No workaround is known.
> >
> > With that definition 99% of our PR are "critical".

Indeed. I file a lot of "critical" PR's for that reason. ;-)

> > A NetBSD-current
> > kernel not booting on a certain hardware is not a critical problem.

I think all parties agree that it's not "as critical" as an
exploitable security loophole. We only disagree on what that means
in terms of some completely arbitary ranking system.

When I broke my elbow, the nurse asked me "on a scale of 1 to 10, how
much pain are you in", so, as I could recount exactly 4 times when I
was in worse pain, and knowing that I'll die eventually, I said "5".
She didn't even bother to recommend an X-Ray. I guess other people in
excruciating pain assess their life differently.

> What I forgot:
>
>        high   A solution is needed as soon as possible.
>
> This is exactly inprecise wording I want to avoid. It only tempts
> submitter to use priority "High" because they want that fix as
> soon as possible.

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.

Frederick