HCoop / bpt / guile.git / blame
| 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 | |
| 5 | from prep.ai.mit.edu; does anyone remember what the filename is? | |
| 6 | ||
| 7 | - Make sure your changes compile and work, at least on your own | |
| 8 | machine, before checking them into the main branch of the Guile | |
| 9 | repository. If you really need to check in untested changes, make a | |
| 10 | branch. | |
| 11 | ||
| 12 | - When you make a user-visible change (i.e. one that should be | |
| 13 | documented, and appear in NEWS, put an asterisk in column zero of the | |
| 14 | start of the ChangeLog entry, like so: | |
| 15 | ||
| 16 | Sat Aug 3 01:27:14 1996 Gary Houston <ghouston@actrix.gen.nz> | |
| 17 | ||
| 18 | * * fports.c (scm_open_file): don't return #f, throw error. | |
| 19 | ||
| 20 | - Include each log entry in both the ChangeLog and in the CVS logs. | |
| 21 | If you're using Emacs, the pcl-cvs interface to CVS has features to | |
| 22 | make this easier; it checks the ChangeLog, and generates good default | |
| 23 | CVS log entries from that. | |
| 24 | ||
| 25 | - If you add or remove files, don't forget to update the 'dist-dir' | |
| 26 | target in the relevant Makefile.in files, so the snapshot and | |
| 27 | distribution processes will work. | |
| 28 | ||
| 29 | - Make sure you have papers from people before integrating their | |
| 30 | changes or contributions. This is very frustrating, but very | |
| 31 | important to do right. From maintain.texi, "Information for | |
| 32 | Maintainers of GNU Software": | |
| 33 | ||
| 34 | When incorporating changes from other people, make sure to follow the | |
| 35 | correct procedures. Doing this ensures that the FSF has the legal | |
| 36 | right to distribute and defend GNU software. | |
| 37 | ||
| 38 | For the sake of registering the copyright on later versions ofthe | |
| 39 | software you need to keep track of each person who makes significant | |
| 40 | changes. A change of ten lines or so, or a few such changes, in a | |
| 41 | large program is not significant. | |
| 42 | ||
| 43 | *Before* incorporating significant changes, make sure that the person | |
| 44 | has signed copyright papers, and that the Free Software Foundation has | |
| 45 | received them. | |
| 46 | ||
| 47 | If you receive contributions you want to use from someone, let me know | |
| 48 | and I'll take care of the administrivia. Put the contributions aside | |
| 49 | until we have the necessary papers. | |
| 50 | ||
| 51 | ||
| 52 | ||
| 53 | Jim Blandy |