X-Git-Url: http://git.marmaro.de/?a=blobdiff_plain;f=docs%2FREADME.developers;h=74c3c07503d49cc1addf6c48d867af08ba4cc982;hb=bff308e43d7bf5fc175fa0aa41a064f051506e28;hp=b384a30fbc7767b5171632b19d9fa2664214e280;hpb=98cf16c3e81c2be2122e16af7d58c2c8cbad9f7e;p=mmh diff --git a/docs/README.developers b/docs/README.developers index b384a30..74c3c07 100644 --- a/docs/README.developers +++ b/docs/README.developers @@ -41,12 +41,23 @@ end-users who don't have any interest in changing the configure-related files and don't have autoconf installed. They'll be unable to make without playing around with `touch'. -The correct order to commit the configure-related files is: +The correct procedure to commit the configure-related files is: -% cvs commit acconfig.h aclocal.m4 config.h.in configure.in configure stamp-h.in + % cvs commit acconfig.h aclocal.m4 configure.in + % autoheader; autoconf; date > stamp-h.in + % cvs commit config.h.in configure stamp-h.in -If you haven't changed all of those files, just commit the rest in the -stated order (e.g. cvs commit acconfig.h config.h.in stamp-h.in). +The reason for the three-step commit is that configure.in contains the RCS $Id +keyword, so when you commit it, a new version is written locally. Therefore, +the autoconf regeneration should be held off until after the commit, or your +local stamp-h.in will become out-of-sync with the CVS version (granted, not that +big a deal). For the second step, you're doing the same commands as a +`make reset' would do, but using that command would require extra configure runs +to make Makefile be up-to-date. + +If you haven't changed all the files noted above, just commit the ones you have +changed, in the stated order (for instance, configure.in, then configure and +stamp-h.in). ------------------- @@ -126,8 +137,26 @@ zotnet/mts/ MTS code not specific to any single MTS apparently goes here. zotnet/tws/ - No idea what "tws" stands for, other than 't' almost certainly standing for - "time". Date and time manipulation routines go here. + "tws" apparently stands for "time with structure", a rather odd phrase. + This directory used to be the place for date and time manipulation code, but + currently nothing in here is compiled. There are new, more portable + versions of the key files in h/ and sbr/, and this directory will soon go + away completely. + + +------------------------------------------------------- +nmh-local functions to use in preference to OS versions +------------------------------------------------------- + +For some system functions whose availability or behavior varies from OS to OS, +nmh conditionally uses a local definition with the same name as the OS function +(e.g. snprintf()). For other functions, developers need to avoid the OS +versions and always use the nmh-supplied function. Here is a list of such +functions: + +OS function nmh-local version to use instead +=========== ================================ +getpass() nmh_getpass() ------------- @@ -137,36 +166,60 @@ releasing nmh To make a public release of nmh (we'll use version 1.0.4 and my mhost.com account, danh, as examples here): -1. % echo 1.0.4 > VERSION + 1. % echo 1.0.4 > VERSION + + 2. Put a comment like "Released nmh-1.0.4." in the ChangeLog. + + 3. % cvs commit ChangeLog VERSION + + 4. % cvs tag nmh-1_0_4 + (cvs treats dots specially, so underscores are substituted here.) + + 5. % make nmhdist + + 6. Untar nmh-1.0.4.tar.gz and `diff -r' it vs. your CVS tree. Make sure no + files got left out of the distribution that should be in it (due to someone + forgetting to update the DIST variables in the Makefiles). + + 7. If you have root access on your machine, it's good at this point to do: + + % chown -R 0:0 nmh-1.0.4 + % tar cvf nmh-1.0.4.tar nmh-1.0.4 + % gzip nmh-1.0.4.tar + + If you leave the files in the archive as being owned by yourself, your UID + may coincide with one of a user on a machine where nmh is being installed, + making it possible for that user to Trojan the nmh code before the system + administrator finishes installing it. -2. Put a comment like "Released nmh-1.0.4." in the ChangeLog. + 8. Make sure your new tarball uncompresses and untars with no problem. Make + sure you can configure, make, and install nmh from it. -3. % cvs commit ChangeLog VERSION + 9. If all is well and your tarball is final, go back to your CVS tree and do: -4. % cvs tag nmh-1_0_4 - (cvs treats dots specially, so underscores are substituted here.) + % echo 1.0.4+dev > VERSION -5. % make nmhdist +10. Put a comment like "Upped the version number to 1.0.4+dev until the next nmh + release." in the ChangeLog. -6. Preferably make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz. +11. % cvs commit ChangeLog VERSION -7. Preferably test out the tarball, making sure you can uncompress and untar it, - and configure, make, install, and use nmh from it. +12. If possible, make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz. -8. % scp -p nmh-1.0.4.tar.gz* your-uid@mhost.com:/home/ftp/pub/nmh +13. % scp -p nmh-1.0.4.tar.gz* danh@mhost.com:/var/ftp/pub/nmh -9. Send an announcement to exmh-users@redhat.com, exmh-workers@redhat.com, - mh-users@ics.uci.edu, and nmh-announce@mhost.com. If the release fixes - significant security holes, also send an announcement to - bugtraq@securityfocus.com. The exmh lists require you to be subscribed in - order to post. Note that you don't need to post separately to comp.mail.mh, - as the mh-users mailing list is apparently bidirectionally gatewayed to it. +14. Send an announcement to exmh-users@redhat.com, exmh-workers@redhat.com, + mh-users@ics.uci.edu, and nmh-announce@mhost.com. If the release fixes + significant security holes, also send an announcement to + bugtraq@securityfocus.com. The exmh lists require you to be subscribed in + order to post. Note that you don't need to post separately to comp.mail.mh, + as the mh-users mailing list is apparently bidirectionally gatewayed to it. - Preferably, the announcement should contain the MD5 hash generated above, and - should be PGP-signed. It should include the FTP URL for the tarball as well - as the URL of the website. It should contain a brief summary of visible - changes, as well as the URL of the cvsweb diff page that would show a - detailed list of changes. The changes between 1.0.3 and 1.0.4 would be shown - by: + Preferably, the announcement should contain the MD5 hash generated above, + and should be PGP-signed. It should include the FTP URL for the tarball as + well as the URL of the website. It should contain a brief summary of + visible changes, as well as the URL of the cvsweb diff page that would show + a detailed list of changes. The changes between 1.0.3 and 1.0.4 would be + shown by: - http://www.mhost.com/cgi-bin/cvsweb/nmh/ChangeLog?r1=1.40&r2=1.71 + http://www.mhost.com/cgi-bin/cvsweb/nmh/ChangeLog?r1=1.40&r2=1.71