[Top][All Lists]

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

Re: More Bug Stuff

From: Marius Vollmer
Subject: Re: More Bug Stuff
Date: 25 Mar 2002 00:03:00 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Evan Prodromou <address@hidden> writes:

> OK, so, here's my collected bug file headers list. It gives the header
> name, arity (can be 0, 1, or Inf), and a description of what it's
> for. Let me know if I'm missing anything here.
> * Number (1)

Do we need a number?  I'd rather go with a symbolic name.  Numbers are
so, umm, 'C'.

> * Title (1)

Why "Title"?  I prefer "Summary" for this.

> * Reported-By (0,1)
>   Name and email address of person who reported the bug, in
>   angle-bracket format. Ex:

Do we need to restrict us to the angle bracket format?  What about
allowing any RFC2822 mailbox?

>   All dates must either be in the above "standard" format, or in the
>   format:
>             dd Mon YYYY

I'd rather use the ISO format YYYY-MM-DD here.  Do we need a time?

> * Priority (0,Inf)

Again, do we need hard numbers for this?  In general, I think it will
be mostly arbitrary what priority number is assigned to a bug.
Identifying critical bugs, and distinguishing bugs from wishlist items
is important, tho.  We can use Severity for this.

> * Severity (0,1)
>   How severe the bug is, in terms of what it does to the user. Field
>   is:

What about using Debian's list of severities:


     makes unrelated 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.


     makes the package in question unuseable or mostly so, or causes
     data loss, or introduces a security hole allowing access to the
     accounts of users who use the package.


     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.


     a bug which has a major effect on the usability of a package,
     without rendering it completely unusable to everyone.  normal the
     default value, applicable to most bugs.


     a problem which doesn't affect the package's usefulness, and is
     presumably trivial to fix.


     for any feature request, and also for any bugs that are very
     difficult to fix due to major design considerations.


     for bugs that are fixed but should not yet be closed. This is an
     exception for bugs fixed by non-maintainer uploads. Note: the
     "fixed" tag should be used instead.

    Certain severities are considered release-critical, meaning the
    bug will have an impact on releasing the package with the stable
    release of Debian. Currently, these are critical, grave and

>   NOTE that Priority and Severity are loosely coupled -- things that
>   are more severe usually will have a high priority, but not
>   necessarily. For example, updating the version string for a release
>   is a high priority task, but it's not particularly severe (it'd be a
>   nuisance).

Are we talking about tasks here as well, in addition to bugs?  For
tasks, priority makes more sense.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]