All bugs which are severity important or above are by definition release
critical, the submitter of the bug can set the severity, the maintainer
can also set the severity..
If the release manager rules that a bug is not release critical he may
also change the severity..
For a explanation of the severity levels please see
http://www.debian.org/Bugs/Developer.html#severities..
Zephaniah E, Hull.
On Sat, Dec 05, 1998 at 09:30:01PM -0800, Oscar Levi wrote:
> Some of these don't really look critical to me. I think of critical
> as something that either causes a loss of data, makes the system
> insecure, or is a glaring error of lesser proportion.
>
> When I have done this in commercial environments, we made a matrix
> like this:
>
> Severe Important Cosmetic
> (crash, hang, (missing or
> security breech) improper feature)
>
> Always 1 1 2
>
> Frequently 1 2 2
>
> Seldom 3 3 3
>
> Rare 4 4 4
>
> This is merely an example. The rankings don't always make sense in
> every situation. The idea is to categorize bugs so that we fix all
> priority 1 bugs, we work hard on priority 2 bugs, and tend to let 3's
> and 4's slide. The priority is set by committee when there is a
> dispute. (Of course, developers want to downgrade the priority so they
> can say they have nothing to do.)
>
> This kind of ranking becomes important at times like this when we are
> attempting to release a product. We agree that we will ship with no
> priority one bugs, with a certain agreed upon number of priority 2's
> and 3's and we tend to forget 4's unless there is nothing better to
> do.
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
PGP EA5198D1-Zephaniah E, Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
Attachment:
pgpLVR8KbJzel.pgp
Description: PGP signature