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
next prev parent 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).