Re: Handling BUGS.

[Thien-Thi Nguyen]

   From: Marius Vollmer <address@hidden>
   Date: 24 Mar 2002 14:37:34 +0100

   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.

ok i understand now.  yes, agreed.  it's the old "how to represent
attributes -- inside or outside" question.

   This is nice.  What about a Gnus mail backend that works on the bug
   data base? ;-)  (Only half joking..)

eventually Gnus interfaces to all trees, so yeah why not?

   I see that we already have a workbook/bugs directory (thanks!).  What
   about putting the following README into it, as a start:

       [field deinition / documentation]

cool.

       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-<n>" where <n> 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.

maybe something like bug-000.no-bugs-database ?  we also need to ask
if/how a bug-000.scm (that would exercise the bug) are to be referenced
and/or included in the database.  keeping such code in the databse might
be less work in the long run (it would be easy to extract them into some
regression/ directory for nightly tests).  maybe something like:

  test-cases: ("bug-000.1.scm" "bug-000.2.scm" ...)

       Meta information about the bug tracking system (like this README
       file) should be put into files that start with a upper case letter.

yeah i like easy-to-understand conventions that "ls" handles
automatically.  :->

thi