diff options
Diffstat (limited to 'HACKING')
-rw-r--r-- | HACKING | 74 |
1 files changed, 74 insertions, 0 deletions
diff --git a/HACKING b/HACKING new file mode 100644 index 000000000..a3cc004b9 --- /dev/null +++ b/HACKING @@ -0,0 +1,74 @@ +Here are some guidelines for working on the Guile source tree at GNU. + +- As for any part of Project GNU, changes to Guile should follow the +GNU coding standards. The standards are available via anonymous FTP +from prep.ai.mit.edu, as /pub/gnu/standards/standards.texi and +make-stds.texi. + +- Check Makefile.in and configure files into CVS, as well as any files +used to create them (Makefile.am, configure.in); don't check in +Makefiles or header files generated by configuration scripts. The +general rule is that you should be able to check out a working +directory of Guile from CVS, and then type "configure" and "make". + +- Make sure your changes compile and work, at least on your own +machine, before checking them into the main branch of the Guile +repository. If you really need to check in untested changes, make a +branch. + +- When you make a user-visible change (i.e. one that should be +documented, and appear in NEWS, put an asterisk in column zero of the +start of the ChangeLog entry, like so: + +Sat Aug 3 01:27:14 1996 Gary Houston <ghouston@actrix.gen.nz> + +* * fports.c (scm_open_file): don't return #f, throw error. + +When you've written a NEWS entry and updated the documentation, go +ahead and remove the asterisk. I will use the asterisks to find and +document changes that haven't been dealt with before a release. + +- Include each log entry in both the ChangeLog and in the CVS logs. +If you're using Emacs, the pcl-cvs interface to CVS has features to +make this easier; it checks the ChangeLog, and generates good default +CVS log entries from that. + +- There's no need to keep a change log for documentation files. This +is because documentation is not susceptible to bugs that are hard to +fix. Documentation does not consist of parts that must interact in a +precisely engineered fashion; to correct an error, you need not know +the history of the erroneous passage. (This is copied from the GNU +coding standards.) + +- If you add or remove files, don't forget to update the appropriate +part of the relevant Makefile.am files, and regenerate the +Makefile.in. If you forget this, the snapshot and distribution +processes will not work. + +- Make sure you have papers from people before integrating their +changes or contributions. This is very frustrating, but very +important to do right. From maintain.texi, "Information for +Maintainers of GNU Software": + + When incorporating changes from other people, make sure to follow the + correct procedures. Doing this ensures that the FSF has the legal + right to distribute and defend GNU software. + + For the sake of registering the copyright on later versions ofthe + software you need to keep track of each person who makes significant + changes. A change of ten lines or so, or a few such changes, in a + large program is not significant. + + *Before* incorporating significant changes, make sure that the person + has signed copyright papers, and that the Free Software Foundation has + received them. + +If you receive contributions you want to use from someone, let me know +and I'll take care of the administrivia. Put the contributions aside +until we have the necessary papers. + +- When you make substantial changes to a file, add the current year to +the list of years in the copyright notice at the top of the file. + + +Jim Blandy |