Peculiar use of bug categories
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".
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.
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.
Comments?
Thomas
--NAA07948.945715853/melbourne-city-street.MIT.EDU--
Reply to: