unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Marius Vollmer <mvo@zagadka.ping.de>
Cc: guile-devel@gnu.org
Subject: Re: More Bug Stuff
Date: 25 Mar 2002 00:03:00 +0100	[thread overview]
Message-ID: <87d6xtzhzv.fsf@zagadka.ping.de> (raw)
In-Reply-To: <873cypn2a2.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us>

Evan Prodromou <evan@glug.org> 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.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2002-03-24 23:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-24 20:23 More Bug Stuff Evan Prodromou
2002-03-24 23:03 ` Marius Vollmer [this message]
2002-03-25  8:21   ` Thien-Thi Nguyen
2002-03-25 15:48     ` Rob Browning
2002-03-25 21:19       ` Thien-Thi Nguyen
2002-03-25 21:35     ` Marius Vollmer
2002-03-25 22:00       ` Thien-Thi Nguyen
2002-03-25 22:03       ` Thien-Thi Nguyen
2002-03-25 22:25         ` Marius Vollmer
2002-03-27  0:31       ` Evan Prodromou
2002-03-27  2:58         ` Thien-Thi Nguyen
2002-03-27 19:09           ` Marius Vollmer
2002-03-27 20:39             ` Thien-Thi Nguyen
2002-04-07 11:17               ` Marius Vollmer
2002-04-07 19:05                 ` Thien-Thi Nguyen
2002-04-07 21:22                   ` Thien-Thi Nguyen
2002-04-07 21:38                   ` Marius Vollmer
2002-03-27 18:56         ` Marius Vollmer
2002-03-28 16:52   ` Evan Prodromou
2002-03-29  4:02     ` Thien-Thi Nguyen
2002-04-07 12:03     ` Marius Vollmer
2002-04-07 22:22       ` Thien-Thi Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d6xtzhzv.fsf@zagadka.ping.de \
    --to=mvo@zagadka.ping.de \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).