> 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". A NetBSD-current
> > kernel not booting on a certain hardware is not a critical problem.
> 
> 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.
> 

In a world where users don't pay in hard currency for the support they 
receive, only the maintainer can really set the priority, when the 
relative importance of all the various problems can be assessed.

My opinion is that generally you can accept the severity measure of a 
user, but you must set the priority yourself.

R.

Of course, if users *are* paying you cash for support, then they get to 
dictate your priorities as well (if you want to keep that money :-)