Re: Peculiar use of bug categories
On Mon, Dec 20, 1999 at 01:50:53PM -0500, Thomas Bushnell, BSG wrote:
>
> Right now, Debian has five bug categories: wishlist, normal,
> important, grave, and critical.
>
> The last three categories are all regarded as "release critical",
> meaning that a release should not go out with any such bugs
> outstanding.
>
> As a consequence, there is a strong reluctance to report bugs with
> those severities, and as a secondary consequence, there is no real
> distinction between important, grave, and critical.
>
> For example, the recent base-files mistake earned a gajillion bug
> reports, which were all but one marked with severity "important".
>
> In fact, the bug made installation of the package utterly impossible,
> and so it should have been marked grave, according to the `bug'
> program: "Makes the package in question unusable by anyone or mostly
> so".
dpkg --force-conflicts --install base-files_2.1.11.deb
Agreed, though, that this could have easily been marked as grave.
> Basically, we are using only three categories: wish-list, normal,
> release-critical. The three shades of meaning within release-critical
> are mostly ignored and not terribly useful.
The recent libreadlineg2-dev bug, however, was certainly grave and not
just important: any packages compiled against version 2.1-13 of the
library were immediately uninstallable (without --force-depends). The
fact that the package (potentially) broke many other packages made
this much more important than, say, acroread segfaulting. In the
latter case, there is no (obvious) external damage, only damage to
package in question. In the former, significant parts of potato would
have ground to a very quick halt (ftp depends on the library, for
example).
I *do* see value in the different severities.
> Most bugs are not release-critical. Accordingly, most of the levels of
> bug-importance categories should be in the non-release-critical
> portion of the spectrum. I would suggest a shifting of the spectrum
> so that one level is for wish-list, two for non-release-critical, and
> two for release-critical.
>
> Brief descriptions of the levels would be:
>
> 0: New feature requests.
> 1: non-release-critical bugs that are minor annoyances, like
> incorrect error messages and such (see, eg, 39396)
> 2: non-release-critical bugs that are significant pains, like (for
> example) 26524.
> 3: release-critical bugs that hose the package in question (like the
> recent base-files problem).
> 4: release-critical bugs that hose other packages, could lead to
> serious data loss, or security hosage.
>
> I have no proposal for how to migrate the current system to this; if
> there is agreement about what to change to, then migration issues
> should be handled then, separately.
There is possible mileage in this; you must consider, however, who uses
the bug severities at present. The difference between the different
release-critical bug reports is the suggested time allowed for the
maintainer to fix the bug before an NMU: I recall reading somewhere
that a critical bug should be fixed within 48 hours, with NMUs in that
period if necessary.
For normal bugs, however, unless someone is looking at the package
with a view of adopting it, requiring maintainers/bug-submitters to
sub-classify the bug report even more finely, there is only
unnecessary effort expended in the task.
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Reply to: