X-Git-Url: https://diplodocus.org/git/nmh/blobdiff_plain/b56c88e2847c582f9b18ae5bbda44f033cd49c42..99f48bb3a2617b5a81355fc45d1198863e6043d0:/docs/README.developers?ds=sidebyside diff --git a/docs/README.developers b/docs/README.developers index 1d3fd737..692f352b 100644 --- a/docs/README.developers +++ b/docs/README.developers @@ -21,6 +21,11 @@ commit checklist 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 @@ -111,9 +116,16 @@ sbr/ 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 .c containing the code for that command @@ -156,6 +168,7 @@ to any new branches that you create: % git config branch.autosetuprebase always + ------------------------------------------------------- nmh-local functions to use in preference to OS versions ------------------------------------------------------- @@ -193,15 +206,24 @@ nmh test suite 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 @@ -211,18 +233,43 @@ To make a public release of nmh (we'll use version 1.5 as the example here; the convention for release candidates is to use something like "1.5-RC1"): - 1. % echo 1.5 > VERSION + 1. Create a release branch. The convention is to name release branches + with the name "-release". + + % git branch 1.5-release + + 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 + % git push --tags + + Then do: + + % git checkout 1.5-release + + You are now on the 1.5 release branch. + + 2. % echo 1.5 > VERSION % date +"%e %B %Y" > DATE (DATE should contain something like "30 December 2000") - 2. % git commit VERSION DATE; git push + 3. % git commit VERSION DATE; git push - 3. % git tag -a 1.5 -m 'Releasing nmh-1.5.' + 4. % git tag -a 1.5 -m 'Releasing nmh-1.5.' + % git push --tags Note that the new convention for tagging is to simply tag with the version number (tag formats in the past have varied). - 4. % make distcheck + 5. % make distcheck If you want to check the distribution build with some particular configure options, set the DISTCHECK_CONFIGURE_FLAGS variable. @@ -230,13 +277,7 @@ here; the convention for release candidates is to use something like % make distcheck DISTCHECK_CONFIGURE_FLAGS=--with-cyrus-sasl - 5. If all is well and your tarball is final, go back to your workspace and do: - - % echo 1.5+dev > VERSION - - 6. % git commit VERSION; git push - - 7. Upload the distribution file to savannah. You can automate this process + 6. Upload the distribution file to savannah. You can automate this process by doing: % make upload SAVANNAH_USERNAME=username @@ -244,13 +285,13 @@ here; the convention for release candidates is to use something like This will automatically call gpg to sign the release. You can bypass this step by setting the SKIP_GPG_SIG variable. - 8. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the CVS + 7. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the CVS 'webpages repository'; see https://savannah.nongnu.org/cvs/?group=nmh) - 9. Add a news item to the savannah nmh page. You'll have to submit it first + 8. Add a news item to the savannah nmh page. You'll have to submit it first and then separately approve it (under News->Manage). -10. Send the release announcement email to the following places: + 9. Send the release announcement email to the following places: nmh-workers@nongnu.org nmh-announce@nongnu.org exmh-users@redhat.com