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: Handling BUGS. Date: 24 Mar 2002 14:37:34 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <87wuw2gk81.fsf@zagadka.ping.de> References: <87g02t4zgn.fsf@raven.i.defaultvalue.org> <87lmcko60l.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> <87elic8k8e.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> <87r8mcgx4m.fsf@gaff.bad-people-of-the-future.san-francisco.ca.us> <87n0x01bci.fsf@raven.i.defaultvalue.org> <87u1r77a7c.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1016976982 20224 127.0.0.1 (24 Mar 2002 13:36:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2002 13:36:22 +0000 (UTC) Cc: rlb@defaultvalue.org, evan@glug.org, 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 16p8AY-0005G5-00 for ; Sun, 24 Mar 2002 14:36:22 +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 16p8AK-0000lY-00; Sun, 24 Mar 2002 08:36:08 -0500 Original-Received: from [195.138.42.204] (helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16p89h-0000jo-00 for ; Sun, 24 Mar 2002 08:35:30 -0500 Original-Received: (qmail 1294 invoked by uid 1000); 24 Mar 2002 13:37:34 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 73 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:174 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:174 Thien-Thi Nguyen writes: > From: Marius Vollmer > Date: 23 Mar 2002 13:14:15 +0100 > > What about calling it "workbook" instead of "devel"? > > that's fine by me. Ok. > I have a slightly uneasy feeling about splitting BUGS into multiple > files. CVS is not very good at moving or renaming files and we > wouldn't have a centralized log any more. I don't see any problems > with just keeping all bugs in one file. > > usually a bug, once interned into the system, should not move (and > should not be deleted). Yes, I was referring to Rob's plan to move resolved bugs into a different directory. When we use one file per BUG, we should not put them into different directories depending on their state. This would be nice for a quick overview, but as you say, we can get this with some simple tools that would also allow for more a flexible categorization. > cd /tmp > render-bugs --dir-slice resolved .../workplace/bugs/ > > creates /tmp/resolved/{3,4,5} (symlinks to .../workplace/bugs/{3,4,5}) > where 3,4,5 are determined to satisfy the pre-defined "resolved" filter. This is nice. What about a Gnus mail backend that works on the bug data base? ;-) (Only half joking..) I see that we already have a workbook/bugs directory (thanks!). What about putting the following README into it, as a start: This directory is the Guile bug data base. It contains one file per bug with a simple, mail-message like format. Each file starts with a number of header lines in the form field-name: field-value where 'field-name' contains no whitespace and is compared case-insensitive. 'field-value' can be continued in the next line by using a '\' as its last character. The header is separated from the body by a blank line. The body is the rest of the file. There is no limit on the length of a line. The following header fields are defined: Summary - a one-line summary of the bug Tags - a comma separated list of symbolic tag names (for example release-critical-1.6) Reported-By: savannah-name Date: yyyy-mm-dd hh:mm:ss [etc.] If you need more header fields, please document them here. The names of the bug files can be chosen arbitrarily, but must start with a lower case letter. If you don't want to use a symbolic name, use a name of the form "bug-" where is the next unused number. these names are used to refer to bugs from within the description of other bugs, and in discussions, so it helps to use mildly descriptive names. Meta information about the bug tracking system (like this README file) should be put into files that start with a upper case letter. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel