Bug system severities
I thought I had posted a message to debian-devel about a new
`severity' feature for the bug system, but it seems that I missed the
list off the recipients ! My previous message is below.
I have now half-implemented the mechanism described below. You can
now set the severity on a bug report using the `severity' command in
the control@bugs mailserver, or by including a Severity:
psuedo-header in your original report.
However, the severities are currently not visible from outside the
bug system - they are not even displayed in the web pages.
Furthermore, there is no documentation.
I propose to remedy both of these faults in due course.
From: email@example.com (Ian Jackson)
Subject: Bug system severities
Date: Thu, 28 Aug 1997 03:28:21 +0100
I hope to have some time over the weekend to implement severities in
the bug system. I propose to do the following:
Every bug will have a new piece of information recorded about it, the
Severity (this name is deliberately different from `priority' or
`importance', both of which have meanings elsewhere). This can be
taken from the psuedo-header if it is present, but we won't
necessarily tell users to do it (just because it'll make life simpler
for them). Knowledgeable people will be able to find out how to do it
by RTFing the developer pages.
You'll also be able to set the severity by mailing control@bugs a new
`severity' command. Relevant package maintainers will of course get
copies of the transcripts for this as they do at the moment, but the
reporter won't be informed about severity changes (it'd probably be
too much junkmail). Perhaps I'll have a way later for reporters and
other people to get such info.
Severity values I propose to have are:
`critical': makes other 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.
`grave': makes the package in question unuseable or mostly so.
(`severe', `serious' and `important' all have other meanings.)
`normal': the default value, for normal bugs.
`wishlist': for any feature request, and also for any bugs that are
very difficult to fix due to major design considerations. I think
it's probably worth lumping these together to keep life simple.
These categories could be expanded later, but for the moment I think
they capture most of the different handling that might be required.
For example, we might consider having a separate `cosmetic' Severity,
but in practice cosmetic bugs probably want to be treated just like
normal ones, and pratting about with the bug system is probably going
to be more effort than just fixing the bug.
Initially the bug system probably wouldn't use this for very much
other than showing things on the indices in different orders, but the
nag messages could be turned off for bugs with `Severity: wishlist'.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .