Start new file which describes maintainer tasks

1 files changed, 82 insertions, 0 deletions

diff --git a/README_maintainer b/README_maintainer
new file mode 100644
index 0000000..37d1494
--- /dev/null
+++ b/README_maintainer
@@ -0,0 +1,82 @@
+
+# -*- mode:org -*-
+
+#+title: Maintainer tasks
+#+startup: indent
+
+This document describes the tasks the Org-mode maintainer has to do
+and how they are performed.
+
+
+* Releases
+
+** Main releases
+
+The release number for main releases look like this:  =7.13=
+
+Main releases are made whenever Org is in a state where the feature
+set is consistent and we feel that the features that are implemented
+is something we want to support in the future.
+
+A major release turns the current state of the master branch into a
+release.  The release process is a single make command:
+
+: make release TAG=7.13
+
+** Minor releases
+
+The release number for minor releases look like this:  =7.13.01=
+
+Minor releases are small amends to main releases.  Usually they fix
+bugs discovered in a main release.  The only yhe fix to the bug is
+bundled into a release, without the main development work going on on
+the master branch.  Since the big fix will also be needed in the
+master branch, usually the fix is made in master and then
+cherry-picked into maint.  When this is done, a release is made from
+maint with this command:
+
+: make fixrelease TAG=7.13.01
+
+* Synchonization with Emacs
+
+This is still a significant headache.  Some hand work is needed here.
+
+Emacs uses bzr, I cannot bring myself to swith from git to bzr for the
+development version of Org-mode.  So the way I have been doing things
+is this:
+
+1. I watch the Emacs diffs for changes made by the maintainers of
+   Emacs in the org-mode files in Emacs.  Any changes that come up
+   there, I merge into the development version of Org-mode.
+   Occasionally I do not do this, if I do not agree with a change.
+   The changes go into Org /without/ a ChangeLog-like entry in the
+   commit message.  The reason for this is that we will later generate
+   a ChangeLog file from our commit messages, and I do not want double
+   Change entries in the Emacs ChangeLog file.
+
+2. When I have made a release (usually I wait for the minor releases
+   to stabilize), I copy org files into the Emacs repository.  Yes, I
+   do not merge, I copy.  This has ben the source of some problems in
+   the past - but I have not had the patience to work out a better
+   mechanism.
+
+   Careful: Copy org.texi and orgcard.tex into the right places, and
+   also copy the lisp files with *two exceptions*: Do *not* copy
+   /org-colview-xemacs.el/ and /org-install.el/.  The former does not
+   belong in Emacs.  And the latter would actually be harmful because
+   Emacs generates its own autoloads.  The Emacs distribution contains
+   an empty org-install.el, so that users can have =(require
+   'org-install)= in .emacs with no ill effects.  So if you were to
+   copy org-install.el, you would overwrite that empty placeholder
+   file.
+
+3. Generate the ChangeLog entries
+
+   For this, I do in the org-mode git repository
+
+   : UTILITIES/make_emacs_changelog release_7.02.05..release_7.03.02
+
+   This will spit out the ChangeLog entries that need to go into the
+   ChangeLog file in the lisp/org directory in Emacs.
+
+