X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/86996fca101c629ef197313a1058df26e01df950..0b7fba1335c0c3fde1eab89e265cbcecf20885a8:/README-hacking

diff --git a/README-hacking b/README-hacking
index 759e08c5..e481da75 100644
--- a/README-hacking
+++ b/README-hacking
@@ -15,25 +15,16 @@ 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.
 
-** If a change fixes a test, mention the test in the ChangeLog entry.
+** If a change fixes a test, mention the test in the log entry.
 
 ** Bug reports
-If somebody reports a new bug, mention his name in the ChangeLog entry
+If somebody reports a new bug, mention his name in the log 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.
 
-** You may find it useful to install the git-merge-changelog merge driver:
-
-  http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
-
-When following the generic installation instructions there, keep in mind that
-your clone of Bison's git repository already contains appropriate
-.gitattributes files, and running Bison's bootstrap script will make the
-necessary changes to .git/config.
-
 
 * Hacking
 
@@ -158,6 +149,20 @@ Register your changes.
 
         $ git checkin ...
 
+For a suggestion of what gnulib commit might be stable enough for a
+formal release, see the ChangeLog in the latest gnulib snapshot at:
+
+        http://erislabs.net/ianb/projects/gnulib/
+
+The autoconf files we use are currently:
+
+        m4/m4.m4
+        lib/m4sugar/m4sugar.m4
+        lib/m4sugar/foreach.m4
+
+These files don't change very often in Autoconf, so it should be
+relatively straight-forward to examine the differences in order to
+decide whether to update.
 
 * Test suite
 
@@ -200,6 +205,10 @@ release:
 
 * Release Procedure
 
+** Update the submodules.  See above.
+
+** Update maintainer tools, such as Autoconf.  See above.
+
 ** Try to get the *.pot files to the Translation Project at least one
 week before a stable release, to give them time to translate them.
 Before generating the *.pot files, make sure that po/POTFILES.in and
@@ -232,12 +241,13 @@ occurrences of PACKAGE_COPYRIGHT_YEAR in configure.ac.
 The version number, *and* the date of the release (including for
 betas).
 
-** Update ChangeLog
-Should have an entry similar to `Version 1.49b.'.
+** Mention the release name in a commit log
+Should have an entry similar to `Version 2.3b.'.
 
 ** Tag the release
-Before Bison will build with the right version number, you must tag the release
-in git.  Do this after all other changes.  The command is similar to:
+Before Bison will build with the right version number, you must tag
+the release in git.  Do this after all other changes.  The command is
+similar to:
 
   git tag -a v2.3b
 
@@ -292,7 +302,7 @@ Here's a brief reminder of how to roll the tarballs and upload them:
 *** put bison-2.3b.tar.gz # This can take a while.
 *** put bison-2.3b.tar.gz.sig
 *** put bison-2.3b.tar.gz.directive.asc
-*** Repeat all these steps for bison-2.3b.tar.bz2.
+*** Repeat all these steps for bison-2.3b.tar.xz.
 
 ** Update Bison manual on www.gnu.org.
 
@@ -367,8 +377,7 @@ Push these changes.
 
 -----
 
-Copyright (C) 2002, 2003, 2004, 2005, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc.
+Copyright (C) 2002-2005, 2007-2012 Free Software Foundation, Inc.
 
 This file is part of GNU Bison.