Add HACKING.

diff --git a/HACKING b/HACKING
new file mode 100644 (file)
index 0000000..bbbda7d
--- /dev/null
+++ b/HACKING
@@ -0,0 +1,116 @@
+-*- outline -*-or
+
+This file attempts to describe the rules to use when hacking Autoconf.
+Don't put this file into the distribution.  Don't mention it in the
+ChangeLog.
+
+* Administrivia
+
+** If you incorporate a change from somebody on the net:
+First, if it is a large change, you must make sure they have signed
+the appropriate paperwork.  Second, be sure to add their name and
+email address to THANKS.
+
+** Test fixes
+If a change fixes a test, mention the test in the ChangeLog entry.
+To this end, the Autotest-mode is handy.
+
+** Bug reports
+If somebody reports a new bug, mention his name in the ChangeLog entry
+and in the test case you write.  Put him into THANKS.
+
+The correct response to most actual bugs is to write a new test case
+which demonstrates the bug.  Then fix the bug, re-run the test suite,
+and check everything in.
+
+** Visible changes
+Which include serious bug fixes, must be mentioned in NEWS.
+
+** Portability issues
+Discoveries in portability matters should be written down in the
+documentation (what fails, why it fails, *where* it fails, and what's
+to be written instead?).
+
+* Test suite
+
+** make check
+Use liberally.
+
+** Release checks
+Try to run the test suite with more severe conditions before a
+release:
+
+- Run `make maintainer-check'
+  This is quite long.  It basically runs the test suite using a C++
+  compiler instead of a C compiler, and within a severe environment
+  (POSIXLY_CORRECT).
+
+- Try some real world packages
+  Good examples include the File, Shell or Text utils.
+
+* Release Procedure
+
+** Tests
+See above.
+
+** Update the foreign files
+Running `make update' in the top level should make it all for you.
+
+** Update configure
+As much as possible, to try an Autoconf that uses itself.  That's
+easy: just be in the top level, and run tests/autoconf.  Or install
+this autoconf and autoreconf -f.
+
+** Update NEWS
+The version number, *and* the date of the release (including for
+betas).
+
+** Update ChangeLog
+Should have an entry similar to `Version 2.53b.'.
+Check all this in once `make distcheck' passes.
+
+** make alpha
+Running `make alpha' is absolutely perfect for beta releases: it makes
+the tarballs, the xdeltas, and prepares (in /tmp/) a proto
+announcement.  It is so neat, that that's what I use anyway for
+genuine releases, but adjusting things by hand (e.g., the urls in the
+announcement file, the ChangeLog which is not needed etc.).
+
+If it fails, you're on your own...
+
+It requires GNU Make.
+
+** Upload
+Put the tarballs/xdeltas where they should be.  Or put it somewhere,
+and send the URL to ftp-upload@gnu.org.
+
+** Bump the version number
+In configure.ac.  Run `make', check this in.
+
+** Announce
+Complete/fix the announcement file, and send it at least to
+info@gnu.org (if a real release, or a ``serious beta''),
+autoconf@gnu.org, automake@gnu.og, libtool@gnu.org, and
+bug-gnu-utils@gnu.org.
+
+
+-----
+
+Copyright (C) 2002 Free Software Foundation, Inc.
+
+This file is part of GNU Autoconf.
+
+GNU Autoconf is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Autoconf is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Autoconf; see the file COPYING.  If not, write to the
+Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+MA 02111-1307, USA.