summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING74
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