merge from upstream

7 files changed, 153 insertions, 144 deletions

diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH
index 53f3d9603ca..9f09135f206 100644
--- a/admin/notes/BRANCH
+++ b/admin/notes/BRANCH
@@ -23,3 +23,10 @@ on what branch at any time.
 If you are looking at this file in a branch other than the trunk,
 there may be some branch-specific documentation below this line.
 ________________________________________________________________________
+
+* elpa
+
+  This branch does not contain a copy of Emacs, but of the Emacs Lisp
+  package archive (elpa.gnu.org).  See admin/notes/elpa for further
+  explanation, and the README file in the branch for usage
+  instructions.
diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index 7c6c0ff4272..04721e4cec3 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -63,13 +63,16 @@ quiet@debbugs.gnu.org.
 ** How do I reply to an existing bug report?
 Reply to 123@debbugs.gnu.org, replacing 123 with the number
 of the bug you are interested in.  NB this only sends mail to the
-bug-list, it does NOT (?) send a CC to the original bug submitter.
+bug-list, it does NOT send a CC to the original bug submitter.
 So you need to explicitly CC him/her (and anyone else you like).
+(This works the same way as all the Emacs mailing lists.  We generally
+don't assume anyone who posts to a list is subscribed to it, so we
+cc everyone on replies.)
 
 (Many people think the submitter SHOULD be automatically subscribed
 to subsequent discussion, but this does not seem to be implemented.
-See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
-See also http://debbugs.gnu.org/5439
+See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078
+See also http://debbugs.gnu.org/5439 )
 
 Do NOT send a separate copy to the bug list address, since this may
 generate a new report.  The only time to send mail to the bug list
@@ -85,9 +88,9 @@ The "owner@debbugs.gnu.org" entry is there because it appears in the
 "Resent-To" header.  For a long time Rmail erroneously included such
 headers in replies.  If you correspond with an Rmail user on a bug,
 these addresses may end up in the Cc.  Mailing to them does nothing
-but create duplicates and errors.  (It is possible you might want to
-have a dialog with the owner address, outside of normal bug
-reporting.)
+but create duplicates and errors.  (It is possible, but unlikely, that
+you might want to have a dialog with the owner address, outside of
+normal bug reporting.)
 
 ** When reporting a bug, to send a Cc to another address
 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
@@ -395,9 +398,14 @@ automatically sets a found version (if none is explicitly specified).
 *** To assign or reassign a bug to a package or list of packages:
 reassign 1234 emacs
 
+Note that reassigning clears the list of found versions, even if the
+new packages includes the original one.
+
 ** To remove spam from the tracker, move it to the `spam' pseudo-package:
 reassign 123 spam
 
+(Should not be necessary any more, now that the input is moderated.)
+
 ** To change the title of a bug:
 retitle 123 Some New Title
 
@@ -484,7 +492,7 @@ Here "{id}" is a literal string, a placeholder that will be replaced
 by the bug number you specify after `--fixes debbugs:' in the bzr
 command line (123 in the example above).
 
-In the bazaar.conf file, this setting should go into the [DEFAULTS]
+In the bazaar.conf file, this setting should go into the [DEFAULT]
 section.
 
 In the locations.conf file, it should go into the branch-specific
diff --git a/admin/notes/bzr b/admin/notes/bzr
index cb2a1bd4e4f..2fdbc2854f8 100644
--- a/admin/notes/bzr
+++ b/admin/notes/bzr
@@ -12,10 +12,17 @@ difficult.
 
 http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
 
+The exception is, if you know that the change will be difficult to
+merge to the trunk (eg because the trunk code has changed a lot).
+In that case, it's helpful if you can apply the change to both trunk
+and branch yourself (when committing the branch change, indicate
+in the commit log that it should not be merged to the trunk; see below).
+
 * Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23").
-Label the commit as a backport, e.g. by starting the commit message with
-"Backport:".  This is helpful for the person merging the release branch
-to the trunk.
+Indicate in the commit log that there is no need to merge the commit
+to the trunk.  Anything that matches `bzrmerge-skip-regexp' will do;
+eg start the commit message with "Backport:".  This is helpful for the
+person merging the release branch to the trunk.
 
 http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
 
@@ -65,11 +72,32 @@ removes a file, then remove the corresponding files by hand.
 The following description uses bound branches, presumably it works in
 a similar way with unbound ones.
 
+0) (First time only) Get the bzr changelog_merge plugin
+(this will be included by default in bzr 2.4 onwards):
+
+cd ~/.bazaar/plugins
+bzr branch http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/trunk 
+mv trunk changelog_merge
+
+This should make merging ChangeLogs smoother.  It merges new entries
+to the top of the file, rather than trying to fit them in mid-way
+through.  Newer versions of the plugin should also be able to deal
+with changes to *old* ChangeLog entries, that should not be floated to
+the head of the file (see launchpad#723968).
+
+Maybe the default Emacs behavior without this plugin is better,
+though, it's not clear yet.
+
 1) Get clean, up-to-date copies of the emacs-23 and trunk branches.
 Check for any uncommitted changes with bzr status.
 
 2) M-x cd /path/to/trunk
 
+The first time only, do this:
+cd .bzr/branch
+Add the following line to branch.conf:
+changelog_merge_files = ChangeLog
+
 3) load admin/bzrmerge.el
 
 4) M-x bzrmerge RET /path/to/emacs-23 RET
@@ -97,9 +125,17 @@ and is due to a technical limitation of bzr.  The log data for those
 revisions gets merged, the actual changes themselves do not.
 http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html )
 
-Note that ChangeLog entries are automatically merged to the top with
-today's date, but you still might want to check them to see that too
-much is not being included, or whitespace between entries is not missing.
+In particular, check the ChangeLog entries (eg in case too many
+entries have been included or whitespace between entries needs fixing).
+bzrmerge tries to fix up the dates to today's date, but it only does
+this where there are conflicts.  If you used the changelog_merge plugin,
+there won't be any conflicts, and (at time of writing) you will need
+to adjust dates by hand.  In any case, if someone made multiple
+ChangeLog entries on different days in the branch, you may wish to
+collapse them all to a single entry for that author in the trunk
+(because in the trunk they all appear under the same date).
+Obviously, if there are multiple changes to the same file by different
+authors, don't break the logical ordering in doing this.
 
 Notes:
 
@@ -119,3 +155,48 @@ right thing to do is merge everything else, resolve the conflict by
 choosing either the trunk or branch version, then run `make -C lisp
 autoloads' to update the md5sums to the correct trunk value before
 committing.
+
+* Re-adding a file that has been removed from the repository
+
+It's easy to get this wrong. Let's suppose you've done:
+
+bzr remove file; bzr commit
+
+and now, sometime later, you realize this was a mistake and file needs
+to be brought back.  DON'T just do:
+
+bzr add file; bzr commit
+
+This restores file, but without its history (`bzr log file' will be
+very short).  This is because file gets re-added with a new file-id
+(use `bzr file-id file' to see the id).
+
+Insteading of adding the file, try:
+
+bzr revert -rN file; bzr commit
+
+where revision N+1 is the one where file was removed.
+
+You could also try `bzr add --file-ids-from', if you have a copy of
+another branch where file still exists.
+
+* Loggerhead
+
+Loggerhead is the bzr tool for viewing a repository over http (similar
+to ViewVC).  The central version is at http://bzr.savannah.gnu.org/lh/emacs,
+but if you just like the way this interface presents data, then if
+you have your own copy of the repository, you can operate your own
+Loggerhead server in stand-alone mode, and so help to reduce the load
+on Savannah:
+
+  bzr branch lp:loggerhead ~/.bazaar/plugins/loggerhead
+  cd /path/to/emacs/bzr
+  bzr serve --http
+
+You may need to install some Python dependencies to get this command to work.
+For example, on RHEL6 I needed:
+
+  yum install python-paste python-simplejson
+  yum --enablerepo=epel install python-simpletal
+
+Then point your web-browser to http://127.0.0.1:8080/ .
diff --git a/admin/notes/copyright b/admin/notes/copyright
index e4077caf77b..39eb003a07d 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -120,7 +120,10 @@ or even ChangeLogs, for older changes. People often installed changes
 from others, without recording the true authorship.
 
 [For reference, most of these points were established via email with
-rms, 2007/1, "Copyright years".]
+rms, 2007/1, "Copyright years".
+
+In March 2011, information on some files no longer included was removed.
+Consult older versions of this document if interested.]
 
 
 lisp/version.el           # emacs-copyright
@@ -143,20 +146,9 @@ lib/Makefile.in
 install-sh
  - this file is copyright MIT, which is OK. Leave the copyright alone.
 
-mkinstalldirs
-src/m/news-r6.h
-  public domain, leave alone.
-
 etc/refcards/*.tex
   also update the \def\year macro for the latest year.
 
-etc/BABYL, ms-kermit
-  no notices (see below).
-
-etc/emacs.csh
- - written by Michael DeCorte, who has no assignment. But trivial
- enough to not need license.
-
 etc/future-bug
  - doesn't need a humorless disclaimer, because Karl Fogel says we
  can consider it part of Emacs, and he has a blanker disclaimer for
@@ -389,9 +381,9 @@ Makefile.in does now.
 src/gmalloc.c
   - contains numerous copyrights from the GNU C library. Leave them alone.
 
-src/acldef.h, chpdef.h, ndir.h
-  - see comments below. These files are OK to be released with Emacs
-  22, but we may want to revisit them afterwards.
+src/ndir.h
+  - see comments below. This file is OK to be released with Emacs
+  22, but we may want to revisit it afterwards.
 
 
 ** Some notes on resolved issues, for historical information only
@@ -402,15 +394,6 @@ which year, I can probably tell you which.) Either way, we have papers
 for it." It was present in Emacs-16.56 (15-jul-85). rms: "Then I
 conclude it was written by me."
 
-etc/ulimit.hack
-  Very obsolete file removed March 2007. Doesn't say who the author
-is, but web-search suggests Karl Kleinpaste, who has no Emacs
-assignment. Trivial anyway.
-http://groups.google.com/group/comp.unix.shell/browse_thread/thread/bf3df496994\
-9f1df/7e5922c67b3a98fb
-http://groups.google.com/group/comp.unix.questions/msg/cc7e49cacfd1ccb4
-    (original 1987 source)
-
 lisp/term/README
   - had no copyright notice till Feb 2007. ChangeLog.3 suggests it was
   written by Eric Raymond. When asked by rms on 14 Feb 2007 he said:
@@ -431,20 +414,6 @@ src/unexhp9k800.c
   HP. So this file is public domain.
 
 
-K Rodgers changes
- It was pointed out that K Rodgers only had assigments for VC and
- ps-print, but had changed several other files. We tried to contact
- him for a general assignment, but he proved uncommunicative (despite
- initially indicating to rms he would sign an assignment). As a result, his
- changes were removed and/or rewritten independently. For details, see
- threads:
-http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00225.html
-http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html
-
- But then an assignment arrived before the release of Emacs 22:
-http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg01427.html
-
-
 lisp/progmodes/python.el
 Dave Love alerted us to a potential legal problem:
 http://lists.gnu.org/archive/html/emacs-pretest-bug/2007-04/msg00459.html
@@ -460,14 +429,8 @@ http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00466.html
 admin/check-doc-strings
   File says it's in the public domain, but that might not make it so.
 
-etc/BABYL
-  File written long ago by authors with no assignment. Keep them
-  without notices for now, try and contact authors if possible. Be
-  ready to remove these files if the authors ever object.
-
-etc/ms-kermit
 etc/e/eterm-color.ti
-src/acldef.h, chpdef.h, ndir.h
+src/ndir.h
   On legal advice from Matt Norwood, the following comment was added
   to these files in Feb/Mar 2007:
 
@@ -480,25 +443,8 @@ src/acldef.h, chpdef.h, ndir.h
   and possibly add a list of all authors who have changed these files.
   (details in email from Matt Norwood to rms, 2007/02/03).
 
-etc/ms-7bkermit
-  Says it was written by Andy Lowry and Joel Spolsky. No entry for
-either in copyright.list. NB this file is not "constrained" like
-ms-kermit (rms: "We know it isn't. A comment at the front says it has
-other bindings which might be handy."). File removed March 2007.
-Re-add if clear up status at some point.
-
-etc/Xkeymap.txt
-  No info on author. File removed March 2007. rms: "It says it is
-RLK's way of remapping his keyboard, so it is not constrained. I think
-it was written by RLK. Let's delete it; if we contact RLK again, we
-can put it back." Actually, RLK == Robert Krawitz has an Emacs
-assignment. So this could be restored if it is still useful, but Jan Djärv
-says it is obsolete:
-<http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00673.html>
-
-src/m/mips4.h, news-risc.h, pmax.h
-src/s/aix3-2.h, bsd386.h, hpux8.h, hpux9.h, irix4-0.h, irix5-0.h,
-netbsd.h, sol2-3.h, usg5-4-2.h
+src/s/aix3-2.h, hpux8.h, hpux9.h, irix5-0.h, netbsd.h, usg5-4-2.h
+  [note some of these have since been merged into other files]
   - all these (not obviously trivial) files were missing copyrights
   till Feb 2007, when FSF copyright was added. Matt Norwood advised:
 
@@ -513,22 +459,6 @@ netbsd.h, sol2-3.h, usg5-4-2.h
 
 Here is my (rgm) take on the details of the above files:
 
-mips4.h
-  might be trivial? started trivial, been added to in tiny changes by
-  those with FSF assignment, often result of email suggestions by others.
-
-news-risc.h
-  started trivial. Grown by tiny additions, plus chunk
-  from mips.h, which was and is Copyright FSF
-
-pmax.h
-  started trivial. grown in tiny changes, except for maybe Jim Wilson's
-  comment.
-
-? irix4-0.h
-  I would say started non-trivial (1992, rms). only tiny changes since
-  installed.
-
 ? irix5-0.h
   I would say started non-trivial (1993, jimb, heavily based
   on irix4-0.h). A few borderline non-tiny changes since.
@@ -537,11 +467,7 @@ usg5-4-2.h
  started non-trivial, but was heavily based on usg5-4.h, which was and is
  copyright FSF. only tiny changes since installed.
 
-sol2-3.h
- started trivial. only non-tiny change (1994) incorporated code from
- usg5-4.h, which was and is copyright FSF.
-
-aix3-2.h, bsd386.h, hpux8.h, hpux9.h, netbsd.h
+aix3-2.h, hpux8.h, hpux9.h, netbsd.h
   started trivial, grown in tiny changes.
 
 netbsd.h:
@@ -556,8 +482,8 @@ Someone might want to tweak the copyright years (for dates before
 Note: erring on the side of caution, I also added notices to some
 files I thought might be considered non-trivial (if one includes
 comment) in s/:
-  aix4-1.h hpux10.h irix6-0.h irix6-5.h
-  ptx4.h sol2.h 
+  aix4-1.h hpux10.h irix6-5.h
+  sol2.h
 
 (everything with > 30 non-blank lines, which at least is _some_ kind of
 system)
@@ -631,10 +557,7 @@ alone (may import them from Gnulib again). These are:
     warn-on-use.h
     lib/*.[ch]
     lib/gnulib.mk
-    src/getloadavg.c
     src/gmalloc.c
-    src/md5.c
-    src/md5.h
     src/termcap.c
     src/tparam.c
 
diff --git a/admin/notes/elpa b/admin/notes/elpa
index e28d81e6d6e..db14456fe32 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -1,42 +1,24 @@
 NOTES ON THE EMACS PACKAGE ARCHIVE
 
-Here are instructions on uploading files to the package archive at
-elpa.gnu.org, for Emacs maintainers.  (If you are not a maintainer,
-contact us if you want to submit a package.)
-
-1. You will need login access to elpa.gnu.org.  You will also need to
-   get the FSF sysadmins to allow ssh access through the FSF firewall
-   for your local machine.  Ensure that your uid, USER, is in the
-   `elpa' group on elpa.gnu.org; this gives you write access to the
-   bzr repository from which the packages are managed.
-
-2. Go to your bzr repository on your local machine.  Of, if you don't
-   have one (you should, if you're tracking Emacs bzr), make one:
-
-     cd $DEVHOME
-     bzr init-repo elpa/
-     cd elpa
-
-   Create a branch for elpa:
-
-     bzr branch bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo package-repo
-
-   Bind the branch:
-
-     cd package-repo/
-     echo "public_branch = bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo" >> .bzr/branch/branch.conf
-     bzr bind bzr+ssh://USER@elpa.gnu.org/home/elpa/package-repo
-
-   Now you should be able to do `bzr up' and `bzr commit'.
-
-3. Changes in bzr do not immediately propagate to the user-facing tree
-   (i.e., what users see when they do `M-x list-packages').  That tree
-   is created by a (daily) cron job that does "bzr export".  If for
-   some reason you need to refresh the user-facing tree immediately,
-   run /home/elpa/bin/package-update.sh as the "elpa" user.
-
-   The Org mode dailies are not part of the repository.  After the
-   package-update.sh script creates the user-facing tree, it copies
-   the daily tarfile hosted on orgmode.org directly into that tree.
-
-4. FIXME: How to actually upload a package file.
+The GNU Emacs package archive, at elpa.gnu.org, is managed using a Bzr
+branch named "elpa", hosted on Savannah.  To check it out:
+
+  bzr branch bzr+ssh://USER@bzr.savannah.gnu.org/emacs/elpa elpa
+  cd elpa
+  echo "public_branch = bzr+ssh://USER@bzr.savannah.gnu.org/emacs/elpa" >> .bzr/branch/branch.conf
+  bzr bind bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/elpa
+  [create task branch for edits, etc.]
+
+Changes to this branch propagate to elpa.gnu.org in a semi-manual way.
+There exists a copy of the elpa branch on that machine.  Someone with
+access logs in, pulls the latest changes from Savannah, and runs a
+"deployment" script.  This script (which is itself kept in the Bzr
+branch) generates the content visible at http://elpa.gnu.org/packages.
+
+The reason we set things up this way, instead of using the package
+upload commands in package-x.el, is to let Emacs hackers conveniently
+edit the contents of the "elpa" branch.  (In particular, multi-file
+packages are stored on the branch in source form, not as tarfiles.)
+
+It is easy to use the elpa branch to deploy a "local" copy of the
+package archive.  For details, see the README file in the elpa branch.
diff --git a/admin/notes/exit-value b/admin/notes/exit-value
index e59bb614b9b..cad6862c8aa 100644
--- a/admin/notes/exit-value
+++ b/admin/notes/exit-value
@@ -10,7 +10,7 @@ different dispatch model that is not explained further here).
 From the point of view of the program, nowadays stdlib.h on both type of
 systems provides macros `EXIT_SUCCESS' and `EXIT_FAILURE' that should DTRT.
 
-NB: The numerical values of these macros DO NOT need to fulfill the the exit
+NB: The numerical values of these macros DO NOT need to fulfill the exit
 value requirements outlined in the first paragraph!  That is the job of the
 `exit' function.  Thus, this kind of construct shows misunderstanding:
 
diff --git a/admin/notes/years b/admin/notes/years
index cdd7cbe4b5f..e6b38c5aefd 100644
--- a/admin/notes/years
+++ b/admin/notes/years
@@ -6,6 +6,14 @@ rolls around, add that year to every FSF (and AIST) copyright notice.
 There's no need to worry about whether an individual file has changed
 in a given year - it's sufficient that Emacs as a whole has changed.
 
+Therefore the years are updated en-masse near the start of each year,
+so basically there is no need for most people to do any updating of them.
+
+The current (in 2011) version of "Information for Maintainers of GNU
+Software" (see that document for more details) says that it is OK to use
+ranges in copyright years, so in early 2011 the years were changed to use
+ranges, which occupy less space and do not grow in length every year.
+
 For more detailed information on maintaining copyright, see the file
 "copyright" in this directory.