Re: More Bug Stuff

[Marius Vollmer]

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:

    critical 

     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.

    grave 

     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.

    serious 

     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.

    important 

     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.

    minor 

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

    wishlist 

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

    fixed 

     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
    serious.

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