From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: More Bug Stuff Date: 25 Mar 2002 00:03:00 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <87d6xtzhzv.fsf@zagadka.ping.de> References: <873cypn2a2.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1017011002 14123 127.0.0.1 (24 Mar 2002 23:03:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2002 23:03:22 +0000 (UTC) Cc: guile-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16pH1F-0003fg-00 for ; Mon, 25 Mar 2002 00:03:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16pH11-0000IP-00; Sun, 24 Mar 2002 18:03:07 -0500 Original-Received: from dialin.speedway42.dip34.dokom.de ([195.138.42.34] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16pGyZ-0000Bo-00 for ; Sun, 24 Mar 2002 18:00:35 -0500 Original-Received: (qmail 1390 invoked by uid 1000); 24 Mar 2002 23:03:00 -0000 Original-To: Evan Prodromou In-Reply-To: <873cypn2a2.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> Original-Lines: 97 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:185 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:185 Evan Prodromou 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