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 | 7 | |
350294b1 JB |
8 | - Check Makefile.in and configure files into CVS, as well as any files |
9 | used to create them (Makefile.am, configure.in); don't check in | |
10 | Makefiles or header files generated by configuration scripts. The | |
11 | general rule is that you should be able to check out a working | |
12 | directory of Guile from CVS, and then type "configure" and "make". | |
13 | ||
795b4217 JB |
14 | - Make sure your changes compile and work, at least on your own |
15 | machine, before checking them into the main branch of the Guile | |
16 | repository. If you really need to check in untested changes, make a | |
17 | branch. | |
18 | ||
19 | - When you make a user-visible change (i.e. one that should be | |
20 | documented, and appear in NEWS, put an asterisk in column zero of the | |
21 | start of the ChangeLog entry, like so: | |
22 | ||
23 | Sat Aug 3 01:27:14 1996 Gary Houston <ghouston@actrix.gen.nz> | |
24 | ||
25 | * * fports.c (scm_open_file): don't return #f, throw error. | |
26 | ||
fa3f45cc JB |
27 | When you've written a NEWS entry and updated the documentation, go |
28 | ahead and remove the asterisk. I will use the asterisks to find and | |
29 | document changes that haven't been dealt with before a release. | |
30 | ||
795b4217 JB |
31 | - Include each log entry in both the ChangeLog and in the CVS logs. |
32 | If you're using Emacs, the pcl-cvs interface to CVS has features to | |
33 | make this easier; it checks the ChangeLog, and generates good default | |
34 | CVS log entries from that. | |
35 | ||
30d14d55 JB |
36 | - There's no need to keep a change log for documentation files. This |
37 | is because documentation is not susceptible to bugs that are hard to | |
38 | fix. Documentation does not consist of parts that must interact in a | |
39 | precisely engineered fashion; to correct an error, you need not know | |
40 | the history of the erroneous passage. (This is copied from the GNU | |
41 | coding standards.) | |
42 | ||
733943b9 TT |
43 | - If you add or remove files, don't forget to update the appropriate |
44 | part of the relevant Makefile.am files, and regenerate the | |
45 | Makefile.in. If you forget this, the snapshot and distribution | |
46 | processes will not work. | |
795b4217 JB |
47 | |
48 | - Make sure you have papers from people before integrating their | |
49 | changes or contributions. This is very frustrating, but very | |
50 | important to do right. From maintain.texi, "Information for | |
51 | Maintainers of GNU Software": | |
52 | ||
53 | When incorporating changes from other people, make sure to follow the | |
54 | correct procedures. Doing this ensures that the FSF has the legal | |
55 | right to distribute and defend GNU software. | |
56 | ||
57 | For the sake of registering the copyright on later versions ofthe | |
58 | software you need to keep track of each person who makes significant | |
59 | changes. A change of ten lines or so, or a few such changes, in a | |
60 | large program is not significant. | |
61 | ||
62 | *Before* incorporating significant changes, make sure that the person | |
63 | has signed copyright papers, and that the Free Software Foundation has | |
64 | received them. | |
65 | ||
66 | If you receive contributions you want to use from someone, let me know | |
67 | and I'll take care of the administrivia. Put the contributions aside | |
68 | until we have the necessary papers. | |
69 | ||
fa3f45cc JB |
70 | - When you make substantial changes to a file, add the current year to |
71 | the list of years in the copyright notice at the top of the file. | |
795b4217 JB |
72 | |
73 | ||
74 | Jim Blandy |