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 log entry.
+** If a change fixes a test, mention the test in the commit message.
** Bug reports
-If somebody reports a new bug, mention his name in the log entry
+If somebody reports a new bug, mention his name in the commit message
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
- Build with -DGNULIB_POSIXCHECK. It suggests gnulib modules that can
fix portability issues.
+- Check with `make syntax-check' if there are issues diagnosed by
+ gnulib.
+
- run `make maintainer-check' which:
- runs `valgrind -q bison' to run Bison under Valgrind.
- runs the parsers under Valgrind.
Bison's included XSLT style sheets with the output of --report=all and
--graph.
+- running `make maintainer-release-check' takes care of running
+ maintainer-check, maintainer-push-check and maintainer-xml-check.
+
- Change tests/atlocal/CFLAGS to add your preferred options. For
instance, `-traditional' to check that the parsers are K&R. Note
that it does not make sense for glr.c, which should be ANSI,
The version number, *and* the date of the release (including for
betas).
-** Mention the release name in a commit log
+** Mention the release name in a commit message
Should have an entry similar to `Version 2.3b.'.
** Tag the release
git tag -a v2.3b
-The log message can be simply:
+The commit message can be simply:
Bison 2.3b