Russ Allbery wrote: > 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.
I agree, but I'd add an additional clause to cover another part of how the severity is interpreted in practice: "or cannot be recovered from via the normal use of the packaging system". In other words, any package that requires magic fiddling with dpkg or the dpkg database to recover from, even to upgrade to a fixed version of that package, has a critical bug. In practice, though, I don't think the distinction between critical, grave, and serious matters much in practice; packages should have few enough RC bugs that any such bug will show up on the top of the package's bug list, so it doesn't really matter how much more than serious it is. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140517194328.GA11576@thin
