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

why the package description bugs should have been "serious" (surprised?)

On Wed, Sep 10, 2003 at 07:05:28PM +0100, Colin Watson wrote:
> As one who didn't get any of Javier's bugs :), I'd've been happy if he'd
> filed them with a more sensible severity and made sure that his list of
> packages was up to date so that a dozen of them didn't end up with
> unknown-package. But apart from that ...

I think the bugs should have been filed with severity: serious.

Think I'm crazy?  This opinion is entirely consistent with the letter
and spririt of the Debian Policy Manual and the definitions of our bug

Policy section 3.4.2 says:

  The description field needs to make sense to anyone, even people who
  have no idea about any of the things the package deals with.

http://www.debian.org/Bugs/Developer#severities says:

    is a severe violation of Debian policy (that is, it violates a
    "must" or "required" directive), or, in the package maintainer's
    opinion, makes the package unsuitable for release.

Only a sophist would argue that "needs to" doesn't mean "must" or
"required".  If your boss says, "Your report needs to be on my desk by
the end of the day," is he just giving you a gentle suggestion, or is he
issuing a mandate.

I reiterate my argument, which I last expounded on last November[1], that
it is unwise to couple the "serious" severity to the policy manual in
this way:

  Until and unless we have an algorithmic process for determining bug
  severity that is largely[1] free of human judgement, we will not have
  objectively defined bug severities.

  Perhaps we can achieve this.  Perhaps we could have a tool like
  reportbug ask the user a series of yes/no questions, and set of answers
  would map to a severity.  To be a reliable mapping, of course, we're
  going to have to do away with broad language like "usefulness" and
  "major effect".

  I propose something different, however.  I suggest we split the

  How about having only *some* of the bug severities be deliberately
  objective?  How about leaving the others to the maintainer's discretion?

  I propose something like this:

  -------------- objectivity threshold
  -------------- "RCness" threshold

  Furthermore, I suggest decoupling policy violations from bug severities.
  Make a "policy-violation" tag that can be applied to bugs.

  The "serious" definition would thus be rewritten to simply:

    A bug which, in the package maintainer's opinion, makes the package
    unsuitable for usage in a production environment.

You can read more of my arguments for this approach in the linked
message.  It's pretty long.  I will note that one part of it has been
effectively implemented already, in the form of the "sarge-ignore" tag.

[1] http://lists.debian.org/debian-project/2002/debian-project-200211/msg00165.html

G. Branden Robinson                |
Debian GNU/Linux                   |     Music is the brandy of the damned.
branden@debian.org                 |     -- George Bernard Shaw
http://people.debian.org/~branden/ |

Attachment: pgp31l_kFxsDV.pgp
Description: PGP signature

Reply to: