Re: Bug severities (was: Re: wterm in potato)
>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> Personally, I think the definition of the `Important'
Anthony> severity is way too self-referential ("This bug is
Anthony> release-critical because it's severity is important or
Anthony> higher. It's severity is important because it's
Anthony> release-critical"). Common sense doesn't seem to be
Anthony> working particularly well ("Of course 8bit support is
Anthony> RC", "Oh come on, obviously it's not"), so I'd like to
Anthony> see important defined more directly, in the same manner
Anthony> that `critical' and `grave' are.
Anthony> FWIW, I think the main use of the `important' level
Anthony> should be for policy violations, rather than usability or
Anthony> security issues (which are already covered by critical
Anthony> and grave). Things like `package is in main, but not
Anthony> DFSG-free' doesn't fit either of `critical' or `grave',
Anthony> but is pretty certainly release-critical. Some other
Anthony> sections of policy probably apply too: not having a
Anthony> copyright file, not have a changelog, really severe
Anthony> non-compliance with the FSSTND/FHS perhaps (/opt/foo,
Anthony> say). Some others obviously don't, of course: not every
Anthony> missing manpage is worth culling the distribution over.
Anthony> Also, I'd like to see the definition of grave, `makes the
Anthony> package in question unusable or mostly so' clarified. I'd
Anthony> assume this means `in a majority of situations', rather
Anthony> than just `in your particular situation'.
Anthony> And just to reiterate: assigning a bug the severity of
Anthony> `normal', doesn't mean ignoring it, it doesn't mean it
Anthony> doesn't particularly matter, and it doesn't even mean it
Anthony> can't be fixed during the freeze. It's just saying "sure,
Anthony> this matters, just not enough to inconvenience every
Anthony> other user of the package because it doesn't work for
Anthony> you".
Out of curiosity: if a package fails to configure properly and maybe
even prevents other packages from being installed using "apt-get
upgrade" (yes - I know a package which does this), what severity would
you give it?
Some issues:
- people with the package already installed might be able to use it
without problem.
- people affected want to able to use apt-get upgrade without first
removing the package or putting it on hold.
- AFAIK this doesn't break policy anyway, so wouldn't meet your new
definition of important. Would grave be appropriate?
IMHO the problem is release critical, what do others think? (actually
the maintainer closed the bug in question after thinking he fixed it,
and I haven't heard from him on the issue since).
What if apt-get upgrade still worked, but produced errors every-time
it tried to configure the broken package? Would the severity stay the
same? Or perhaps you would make it lower? This is another problem
I frequently encounter, but all occurrences have been fixed.
In the past, I have put both categories of bugs as important.
--
Brian May <bam@debian.org>
Reply to: