Re: On Bugs

[Brian May <bam@debian.org>]

>>>>> "Christian" == Christian Pernegger <pernegger@chello.at> writes:

    Christian> I'd have classified the color-blind bug normal. That
    Christian> doesn't mean it isn't important, after all.

... so some bugs that are classified as "normal" really are "important".

Sorry, couldn't resist. ;-)

However, it does raise the issue that the severity "important"
is ambiguous, and perhaps should be renamed. 

Or, following on from another post, perhaps the problem is that we are
expecting too much from one field. Perhaps severity could be broken up
into several fields, eg:

release-critical: yes/no
security-risk: root/single-user/none
data-loss: root/single-user/single-directory/single-file/mail-loss/none
policy-violation: section 2.1.2 and section 3.3.6
reproducible: yes/no
distribution: =slink and >>woody
[...]

Notice, that all of these, except the first, is non-subjective.
Typically, the non-subjective fields would allow the release manager
to have some sort of criteria to set the subjective field(s). This
criteria could be changed as the release date approaches.

--- cut ---
I have mixed feelings about this field:

effects: all blind users/all users stupid enough to use this obscure
         option/all users who want main software to be DFSG software/
         all non-English speaking users/etc

as while important to know what users it will affect, it is rather
subjective, too. Next try:

effects: 50% of debian users.
--- cut ---

For this to work, it has to be dead easy for maintainers to make
changes to these values (in case of disagreements with the
submitter). Currently, I think it is too hard, unless you can remember
the format of the E-Mail required (otherwise you have to look up the
documentation, while easy to find, it takes time which could be better
used elsewhere). I think some sort of user-friendly dialog system
would be ideal.
-- 
Brian May <bam@debian.org>