Re: Handling BUGS.

[Marius Vollmer]

Thien-Thi Nguyen <address@hidden> writes:

>    From: Marius Vollmer <address@hidden>
>    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-<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.

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