Commit | Line | Data |
---|---|---|
795b4217 JB |
1 | Here are some guidelines for working on the Guile source tree at GNU. |
2 | ||
3 | - As for any part of Project GNU, changes to Guile should follow the | |
4 | GNU coding standards. The standards are available via anonymous FTP | |
80b4c4fc JB |
5 | from prep.ai.mit.edu, as /pub/gnu/standards/standards.texi and |
6 | make-stds.texi. | |
795b4217 JB |
7 | |
8 | - Make sure your changes compile and work, at least on your own | |
9 | machine, before checking them into the main branch of the Guile | |
10 | repository. If you really need to check in untested changes, make a | |
11 | branch. | |
12 | ||
13 | - When you make a user-visible change (i.e. one that should be | |
14 | documented, and appear in NEWS, put an asterisk in column zero of the | |
15 | start of the ChangeLog entry, like so: | |
16 | ||
17 | Sat Aug 3 01:27:14 1996 Gary Houston <ghouston@actrix.gen.nz> | |
18 | ||
19 | * * fports.c (scm_open_file): don't return #f, throw error. | |
20 | ||
21 | - Include each log entry in both the ChangeLog and in the CVS logs. | |
22 | If you're using Emacs, the pcl-cvs interface to CVS has features to | |
23 | make this easier; it checks the ChangeLog, and generates good default | |
24 | CVS log entries from that. | |
25 | ||
30d14d55 JB |
26 | - There's no need to keep a change log for documentation files. This |
27 | is because documentation is not susceptible to bugs that are hard to | |
28 | fix. Documentation does not consist of parts that must interact in a | |
29 | precisely engineered fashion; to correct an error, you need not know | |
30 | the history of the erroneous passage. (This is copied from the GNU | |
31 | coding standards.) | |
32 | ||
795b4217 JB |
33 | - If you add or remove files, don't forget to update the 'dist-dir' |
34 | target in the relevant Makefile.in files, so the snapshot and | |
35 | distribution processes will work. | |
36 | ||
37 | - Make sure you have papers from people before integrating their | |
38 | changes or contributions. This is very frustrating, but very | |
39 | important to do right. From maintain.texi, "Information for | |
40 | Maintainers of GNU Software": | |
41 | ||
42 | When incorporating changes from other people, make sure to follow the | |
43 | correct procedures. Doing this ensures that the FSF has the legal | |
44 | right to distribute and defend GNU software. | |
45 | ||
46 | For the sake of registering the copyright on later versions ofthe | |
47 | software you need to keep track of each person who makes significant | |
48 | changes. A change of ten lines or so, or a few such changes, in a | |
49 | large program is not significant. | |
50 | ||
51 | *Before* incorporating significant changes, make sure that the person | |
52 | has signed copyright papers, and that the Free Software Foundation has | |
53 | received them. | |
54 | ||
55 | If you receive contributions you want to use from someone, let me know | |
56 | and I'll take care of the administrivia. Put the contributions aside | |
57 | until we have the necessary papers. | |
58 | ||
59 | ||
60 | ||
61 | Jim Blandy |