Re: Bug severity and release-critical status
Ben Finney <email@example.com> writes:
> The decision of whether a bug is release-critical or not is for the
> release managers to make, using the various properties of the bug
> (including but *not* limited to its severity) as input to that
> decision. They can, in fact, make that decision apparent in the bug
> report *without* altering the severity level.
Well, except in practice, many of the tools in Debian work a lot better if
bugs that are of severity critical, grave, or serious are release-critical
and bugs that are not of one of those severities are not. The severity is
tied to release criticality for practical reasons. For example, I don't
know of any way for the release managers to mark a bug as release-critical
for the various reporting and migration tools other than changing its
severity (and setting severity: serious is the standard way of doing
> So, it's not correct for anyone but a release manager to decide “this
> bug is/is not release-critical, so I'll change the severity”; that is a
> perversion of the meaning of the severity field. You can argue about
> whether a bug fits the definition of a specific severity level, and
> change the severity field value on that basis; but whether the bug “is
> release-critical” has no place in that argument.
I guess I can kind of see what you're driving at. But on the other hand,
we shouldn't put all the weight on the release managers to review every
bug in Debian and decide whether it's release-critical. They publish
release criteria, and I think the rest of us should try to at least take a
first pass to save them work.
Generally, the maintainer of the package gets to make the first call on
whether or not a bug is release-critical. They may be overridden, but I
bet most of those decisions stick.
Long term, where I'd like to get us is to where anyone can read Policy and
from that tell what problems are release-critical and what aren't, and
keep policy closely in sync with the release criteria (with, of course,
additional rules that aren't release-critical but are still normally the
right thing to do). We're some distance from that at present.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>