7. update/close bug report (with commit id)?
8. notify nmh-users?
+A buildbot at http://orthanc.ca:8010/waterfall polls for new commits and
+builds them on a few platforms. Keep an eye on its progress in case
+you've committed something non-portable. (If you can provide another
+platform, contact the nmh-workers list.)
+
---------------------------------
C library/system call usage notes
file. These functions are of general use and are called from throughout
nmh.
+SPECS/
+ Contains files such as RPM specs.
+
test/
The num unit test suite.
+tools/
+ "tools" contains tools, scripts, and supporting files used by the
+ developers while writing, debugging, and testing the code.
+
uip/
"uip" stands for "User Interface Programs". Most nmh commands have a file
in this directory named <command>.c containing the code for that command
% git config branch.autosetuprebase always
+
-------------------------------------------------------
nmh-local functions to use in preference to OS versions
-------------------------------------------------------
The nmh test suite is run through the Makefile, with "make check"
or "make distcheck".
+In the nmh test suite, nmh programs to be tested should be invoked
+through the run_test or run_prog shell functions defined in
+test/common.sh.
+
+Instead of echoing test progress, use start_test()/finish_test()
+from tests/common.sh. These will report the particular test name,
+within the test, only if there is a failure.
+
To enable the use of valgrind, where available, set the environment
variable NMH_VALGRIND to a non-null value. However, a separate
environment variable, VALGRIND_ME, triggers the use of valgrind in
test/inc/test-eom-align because it greatly extends the duration of
that test.
-In the nmh test suite, nmh programs to be tested should be invoked
-through the run_test or run_prog shell functions defined in
-test/common.sh.
+If valgrind complains about "serious error when reading debuginfo"
+from a library, either update or remove the debuginfo package for
+the offending library.
+
-------------
releasing nmh
Note you are still on the master branch at this point. Mark the
current revision as the branchpoint for the new release branch:
-
+
% git tag -a -m "This tag marks the point where we started the branch for 1.5" 1.5-branchpoint
Now mark the master branch with a post-release version number (the
convention here is to use VERSION+dev as the version number).
% echo 1.5+dev > VERSION
- % git commit VERSION; git push --tags
+ % git commit VERSION
+ % git push
+ % git push --tags
Then do:
% date +"%e %B %Y" > DATE
(DATE should contain something like "30 December 2000")
- 3. % git commit VERSION DATE
+ 3. % git commit VERSION DATE; git push
4. % git tag -a 1.5 -m 'Releasing nmh-1.5.'
% git push --tags