mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-05-23 13:00:34 +02:00
68 lines
2.9 KiB
Text
68 lines
2.9 KiB
Text
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.
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
Jim Blandy
|