/[guile]/guile/workbook/bugs/README
ViewVC logotype

Contents of /guile/workbook/bugs/README

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.9 - (show annotations) (download)
Thu May 16 21:42:34 2002 UTC (21 years, 11 months ago) by rlb
Branch: MAIN
CVS Tags: HEAD
Changes since 1.8: +5 -0 lines
*** empty log message ***

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

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26