1 |
-*-text-*- |
2 |
This directory is the Guile bug data base. |
3 |
|
4 |
It contains one file per bug with a simple, mail-message like format. |
5 |
|
6 |
[For quick start adding a bug, see TEMPLATE. Also, remember to add its |
7 |
summary under "fix bugs" under "Eventually" in the TODO file.] |
8 |
|
9 |
Each bug file starts with a number of header lines in the form |
10 |
|
11 |
field-name: field-value |
12 |
|
13 |
where 'field-name' contains no whitespace and is compared |
14 |
case-insensitive. 'field-value' can be continued in the next line by |
15 |
using a '\' as the last character of the current line. The header is |
16 |
separated from the body by a blank line. The body is the rest of the |
17 |
file. There is no limit on the length of a line. |
18 |
|
19 |
The following header fields are defined. They are optional except |
20 |
when noted. Also, specific fields can be present more than once, |
21 |
except when noted. |
22 |
|
23 |
Summary: <text> |
24 |
|
25 |
A one-line summary of the bug. Mandatory. |
26 |
|
27 |
Tags: tag1, tag2, ... |
28 |
|
29 |
A comma separated list of symbolic tag names (for example |
30 |
release-critical-1.6). Tags can be used to collect bugs into |
31 |
ad-hoc groups. See the file TAGS for a list of active tags and |
32 |
their meaning. |
33 |
|
34 |
NOTE: Don't add or remove release-critical tags without |
35 |
authorization if the release has been branched in CVS -- see |
36 |
../build/release.txt for details. |
37 |
|
38 |
Reported: mailbox, yyyy-mm-dd |
39 |
|
40 |
The mail address of the reporter, in RFC2822 mailbox format, |
41 |
followed by the date of the report, in ISO8601 format. |
42 |
|
43 |
Assigned: mailbox, yyyy-mm-dd |
44 |
|
45 |
The developer who is working on a fix, and since when. |
46 |
|
47 |
Fixed: mailbox, yyyy-mm-dd [, module [, branch]] |
48 |
|
49 |
The developer who fixed it, when, and in what module and branch if |
50 |
applicable. |
51 |
|
52 |
Affects: branch-or-version, ... |
53 |
|
54 |
A list of branch tags or version numbers of released tar balls |
55 |
that are affected by the bug. |
56 |
|
57 |
If you need more header fields, please document them here. |
58 |
|
59 |
The names of the bug files can be chosen almost arbitrarily. They |
60 |
must start with a lower case letter or a digit and must not contain a |
61 |
"." character. If you don't want to use a symbolic name, use the |
62 |
next unused number. These names are used to refer to bugs from within |
63 |
the description of other bugs, and in discussions, so it helps to use |
64 |
mildly descriptive names. Files or directories that are related to a |
65 |
bug, like test programs that invoke the bug, should get the name of |
66 |
the bug plus a "."-separated extension, like "bug-1.scm". |
67 |
|
68 |
Meta information about the bug tracking system (like this README file) |
69 |
should be put into files that start with a upper case letter. |
70 |
|
71 |
|
72 |
---------------------------------------------------------------------- |
73 |
fyi, ttn's bug-naming convention: |
74 |
NUMBER-NP-VP (noun phrase, verb-phrase), NUMBER starts at 1000. |
75 |
also, i like to put related files in subdir NUMBER.stuff/ |
76 |
and include (as a reminder) the header: "see-also-dir: NUMBER.stuff". |
77 |
i've also started to use header "test-case: PROG (COMMENT)" -- one |
78 |
or more -- to name files in NUMBER.stuff/ that may be used for testing. |
79 |
FOO's extension means: |
80 |
.scm run it like: "guile -s FOO" |
81 |
.sh file is shell script, chmod +x, just run it |