Re: More Bug Stuff

[Marius Vollmer <mvo@zagadka.ping.de>]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> on the other hand, single file at top is simple and here.  so really, my
> proposal (now -- please ignore previous) comes down to:
> 
>         N  -- the rfc822 for bug N
>         .N -- the directory w/ all of bug N's related files;
>               may be empty or absent

What I have now put into workbook/bugs/README is this

          N      --  the rfc822-look-a-like for bug N, where N can be a
                     number or a alphanumeric name and may not contain a "."
          N.ext  --  A file or directory related to bug N.
                     "ext" can be anything.

> in the headers, this would add required header:
> 
> 	bug-stuff-dir: .N

Why required?


Here is the README as it stands now.  The list of headers is not
really meant to be complete, but should be enough for a start.  I'll
start to move the HEAD BUGS file into the new format now.


    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 the last character of the current line.  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.  They are optional except
    when noted.  Also, specific fields can be present more than once,
    except when noted.

      Summary: <text>

        A one-line summary of the bug.  Mandatory.

      Tags: tag1, tag2, ...  

        A comma separated list of symbolic tag names (for example
        release-critical-1.6).  Tags can be used to collect bugs into
        ad-hoc groups.

      Reported: mailbox, yyyy-mm-dd

        The mail address of the reporter, in RFC2822 mailbox format,
        followed by the date of the report, in ISO8601 format.

      Assigned: mailbox, yyyy-mm-dd

        The developer who is working on a fix, and since when.

      Fixed: mailbox, yyyy-mm-dd

        The developer who fixed it, and when.

      Affects: version, version, ...

        A list of branch tags or version numbers of released tar balls
        that are affected by the bug.

    If you need more header fields, please document them here.

    The names of the bug files can be chosen almost arbitrarily.  They
    must start with a lower case letter or a digit and must not contain a
    "."  character.  If you don't want to use a symbolic name, use 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.  Files or directories that are related to a
    bug, like test programs that invoke the bug, should get the name of
    the bug plus a "."-separated extension, like "bug-1.scm".

    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