Redefining critical bug severity (was: how to deal with a missed so bump already uploaded ?)

[Russ Allbery <rra@debian.org>]

Julien Cristau <jcristau@debian.org> writes:
> On Sat, May 17, 2014 at 07:33:04 +0200, Tobias Frost wrote:

>> IMHO the severity should be raised to critical as it breaks unrelated
>> software.

> Reverse dependencies are anything but unrelated.

Over the years, I've seen endless confusion about the current definition
of a critical bug severity:

    makes unrelated software on the system (or the whole system) break, or
    causes serious data loss, or introduces a security hole on systems
    where you install the package.

The confusion seems to always be around the "unrelated software" part of
that definition.  The intended meaning is completely unrelated software on
the system, indicating a package that's mangling the system in some
fundamental way, but I've frequently seen people believe, sincerely, that
reverse dependencies, Perl programs that use a buggy module, or X programs
on a system with a buggy video driver qualify as unrelated software.

This makes me think that part of the bug definition is adding more
confusion than clarity.  Should we just drop it?

I think defining critical as:

    makes the entire system unusable, or causes serious data loss, or
    introduces a security hole on systems where you install the package

is closer to how we actually use the severity, and would avoid some of
these bug severity arguments.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>