Added docs/README.start-devel, which recommends who to start with nmh.
[mmh] / docs / README.developers
index 31a6e46..935d0d1 100644 (file)
@@ -16,7 +16,7 @@ autoconf files
 If you wish to change the `configure' script or its related files, you'll need
 to first install GNU m4, available from <ftp://ftp.gnu.org/pub/gnu/m4/> and then
 GNU autoconf (<ftp://ftp.gnu.org/pub/gnu/autoconf/>).  Nmh is currently using
-a minimum of autoconf 2.54.
+a minimum of autoconf 2.61.
 
 Most of the configure-related files are automatically generated.  The only files
 you should need to manually edit are acconfig.h and configure.ac.  Don't, for
@@ -38,7 +38,7 @@ directory structure
 Following is a list of nmh's directories along with a brief description of the
 purpose of each one.  Meanings are given for the abbreviations, but note that
 these meanings are just informed guesses as to what the MH developers were
-thinking. 
+thinking.
 
 ./
     The top-level directory.  Contains files like README and INSTALL.
@@ -47,7 +47,7 @@ config/
     Contains utility files for the `configure' process.  Ordinarily nothing in
     here needs to be messed with.
 
-doc/
+docs/
     Contains more specialized documentation, such as this file and
     the FAQ.
 
@@ -63,27 +63,11 @@ man/
     Contains all the input files that are processed to generate nmh's manual
     pages.
 
-mts/
-    "mts" stands for "Message Transfer Service".  Source files specific to the
-    different MTSs go in the subdirectories.
-
-mts/mmdf/ (deprecated)
-    "mmdf" stands for "Multichannel Memorandum Distribution Facility".  It is an
-    alternative to sendmail used primarily on SCO UNIX.
-
-mts/sendmail/ (deprecated: handled by mts.conf)
-    When nmh is configured --with-mts=sendmail, the files in this directory are
-    used. 
-
-mts/smtp/
-    When nmh is configured to just talk to an SMTP server over TCP/IP, the
-    source in this directory is compiled.
-
 sbr/
     "sbr" stands for "subroutine(s)".  For the most part, each source file in
     this directory contains a single function with the same name as the source
     file.  These functions are of general use and are called from throughout
-    nmh.  
+    nmh.
 
 uip/
     "uip" stands for "User Interface Programs".  Most nmh commands have a file
@@ -92,32 +76,6 @@ uip/
     <command>sbr.c which contains additional subroutines called from <command>.c
     (which would contain not much else besides main()).
 
-zotnet/ (deprecated)
-    Files in this hierarchy were either written by or moved here by UCI
-    (University of California, Irvine) after they took over MH from the Rand
-    Corporation.  "Zot!" is the sound effect made by the anteater in the "B.C."
-    comic strip when its tongue lashes out at ants.  The anteater is UCI's
-    official mascot.  Not sure whether UCInet was once called ZotNet...
-
-zotnet/bboards/ (deprecated)
-    UCI added Bulletin Board functionality to MH with the `bbc' command.  This
-    functionality has been removed from nmh but apparently files in this
-    directory are still needed for other purposes.
-
-zotnet/mf/ (deprecated, now in sbr/)
-    "mf" stands for "Mail Filter".  The filtering in this case apparently refers
-    to translation between different address and mailbox formats.
-
-zotnet/mts/ (deprecated, now in sbr/)
-    MTS code not specific to any single MTS apparently goes here.
-
-zotnet/tws/ (deprecated, now in sbr/)
-    "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.
-
 
 ---
 git
@@ -130,6 +88,11 @@ the nmh repository:
 
     % git clone git://git.savannah.nongnu.org/nmh.git
 
+That will create a workspace called nmh. To update that workspace
+with changes to the master, cd to it and run:
+
+    % git pull
+
 
 -------------------------------------------------------
 nmh-local functions to use in preference to OS versions
@@ -139,7 +102,7 @@ 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: 
+functions:
 
 OS function  nmh-local version to use instead
 ===========  ================================
@@ -150,28 +113,26 @@ getpass()    nmh_getpass()
 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; the convention for release candidates
-is to use something like "1.0.4-RC1"):
+To make a public release of nmh (we'll use version 1.0.4 as examples
+here; the convention for release candidates is to use something like
+"1.0.4-RC1"):
 
  1. % echo 1.0.4 > VERSION
     % date +"%e %B %Y" > DATE
     (DATE should contain something like "30 December 2000")
 
- 2. Put a comment like "Released nmh-1.0.4." in the ChangeLog.
-
- 3. % cvs commit ChangeLog VERSION DATE
+ 2. % git commit VERSION DATE; git push
 
- 4. % cvs tag nmh-1_0_4
-    (cvs treats dots specially, so underscores are substituted here.)
+ 3. % git tag -a nmh-1_0_4 -m 'Releasing nmh-1_0_4.'
 
- 5. % make nmhdist
+ 4. % 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).
+ 5. Untar nmh-1.0.4.tar.gz and `diff -r' it vs. your workspace.  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:
+ 6. 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
@@ -182,26 +143,23 @@ is to use something like "1.0.4-RC1"):
     making it possible for that user to Trojan the nmh code before the system
     administrator finishes installing it.
 
- 8. Make sure your new tarball uncompresses and untars with no problem.  Make
+ 7. Make sure your new tarball uncompresses and untars with no problem.  Make
     sure you can configure, make, and install nmh from it.
 
- 9. If all is well and your tarball is final, go back to your CVS tree and do:
+ 8. If all is well and your tarball is final, go back to your workspace and do:
 
     % echo 1.0.4+dev > VERSION
 
-10. Put a comment like "Upped the version number to 1.0.4+dev until the next nmh
-    release." in the ChangeLog.
-
-11. % cvs commit ChangeLog VERSION
+ 9. % git commit VERSION; git push
 
-12. If possible, make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz.
+10. If possible, make an MD5 hash and/or a PGP signature of nmh-1.0.4.tar.gz.
     Assuming you have gpg set up, this should be:
     % gpg --output nmh-1.0.4.tar.gz.sig --detach-sig nmh-1.0.4.tar.gz
 
     You can verify the signature with
     % gpg --verify nmh-1.0.4.tar.gz.sig nmh-1.0.4.tar.gz
 
-13. Upload the files to savannah. First make sure they are mode 664 so
+11. Upload the files to savannah. First make sure they are mode 664 so
     they will have the right permissions on the server end
     (see https://savannah.gnu.org/maintenance/SharedDownloadArea)
     % chmod 664 nmh-1.0.4.tar.gz*
@@ -209,13 +167,13 @@ is to use something like "1.0.4-RC1"):
     Then scp them across:
     % scp -p nmh-1.0.4.tar.gz* youruser@dl.sv.nongnu.org:/releases/nmh/
 
-14. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the 'webpages
-    repository'; see https://savannah.nongnu.org/cvs/?group=nmh)
+12. Update the http://www.nongnu.org/nmh/ homepage. (It lives in the CVS
+    'webpages repository'; see https://savannah.nongnu.org/cvs/?group=nmh)
 
-15. Add a news item to the savannah nmh page. You'll have to submit it first
+13. Add a news item to the savannah nmh page. You'll have to submit it first
     and then separately approve it (under News->Manage).
 
-16. Send the release announcement email to the following places:
+14. Send the release announcement email to the following places:
      nmh-workers@nongnu.org
      nmh-announce@nongnu.org
      exmh-users@redhat.com
@@ -232,9 +190,10 @@ is to use something like "1.0.4-RC1"):
     Preferably, the announcement should contain the MD5 hash generated above,
     and should be PGP-signed.  It should include the 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.2 and 1.3 would be
-    shown by:
+    visible changes, as well as the URL of the git diff page that would show
+    a detailed list of changes.  The changes between 1.5 and 1.4 would be
+    shown by [this is just a guess, I don't know anything about cgit, and
+    it assumes that we tag with nmh-x_x-release from now on]:
 
-        http://cvs.savannah.gnu.org/viewvc/nmh/ChangeLog?root=nmh&r1=1.215&r2=1.254.2.13
+        http://git.savannah.gnu.org/cgit/nmh.git/diff/?h=nmh-1_5-release?h=nmh-1_4-release