1 ================================================================
4 * This file attempts to describe the rules to use when hacking
7 * Don't put this file into the distribution. Don't mention it in the
11 ================================================================
14 * If you incorporate a change from somebody on the net:
15 First, if it is a large change, you must make sure they have signed the
16 appropriate paperwork.
17 Second, be sure to add their name and email address to THANKS
19 * If a change fixes a test, mention the test in the ChangeLog entry.
21 * If somebody reports a new bug, mention his name in the ChangeLog entry
22 and in the test case you write. Put him into THANKS.
24 * The correct response to most actual bugs is to write a new test case
25 which demonstrates the bug. Then fix the bug, re-run the test suite,
26 and check everything in.
28 * Some files in the automake package are not owned by automake. These
29 files should never be edited here. These files are COPYING, INSTALL,
30 ansi2knr.1, ansi2knr.c, config.guess config.sub, install-sh, mdate-sh,
31 missing, mkinstalldirs, texinfo.tex
33 * Changes other than bug fixes must be mentioned in NEWS
36 ================================================================
39 * Always use $(...) and not ${...}
41 * Use `:', not `true'. Use `exit 1', not `false'.
43 * Use `##' comments liberally. Comment anything even remotely
46 * Never use basename or dirname. Instead use sed
49 ================================================================
50 = Editing automake.in and aclocal.in
52 * Follow existing indentation style.
54 * Use only Perl 4 constructs
57 ================================================================
60 * Use "make check" and "make maintainer-check" liberally
62 * Make sure each test file is executable
65 ================================================================
68 * Fetch new versions of the files that are maintained by the FSF.
69 Commit. Unfortunately you need an FSF account to do this.
71 * Update NEWS. For an alpha release, update README-alpha.
73 * Update the version number in configure.in.
74 (The idea is that every other alpha number will be a net release.
75 The repository will always have its own "odd" number so we can easily
76 distinguish net and repo versions.)
78 * Configure, build, and install.
80 * Run aclocal, automake, and autoconf.
86 * Put new release on ftp site and send announcement.
87 (If not an alpha, announcement must also go to FSF.)
89 * Update version number in configure.in to next alpha number.
90 Re-run autoconf and commit.