[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: