auto upstream

7 files changed, 29 insertions, 359 deletions

diff --git a/admin/ChangeLog b/admin/ChangeLog
index a75094fa3f1..fa001ede6cb 100644
--- a/admin/ChangeLog
+++ b/admin/ChangeLog
@@ -1,3 +1,10 @@
+2013-01-03  Glenn Morris  <rgm@gnu.org>
+
+        * check-doc-strings: Update for CVS->bzr, moved lispref/ directory.
+
+        * emacs-pretesters, make-announcement, make-changelog-diff:
+        Remove files.
+
 2012-12-14  Paul Eggert  <eggert@cs.ucla.edu>
 
         Fix permissions bugs with setgid directories etc. (Bug#13125)
diff --git a/admin/README b/admin/README
index 5e410e10457..d696a14176e 100644
--- a/admin/README
+++ b/admin/README
@@ -24,10 +24,6 @@ Instructions to create pretest or release tarballs, announcements, etc.
 
 Utilities for setting version numbers and alike.
 
-** make-announcement, make-changelog-diff
-
-Scripts used to prepare release announcements.
-
 
 * Scripts that can be used to build and test Emacs.
 
diff --git a/admin/check-doc-strings b/admin/check-doc-strings
index ef4b203cd79..c69ff47ebfb 100755
--- a/admin/check-doc-strings
+++ b/admin/check-doc-strings
@@ -17,7 +17,7 @@ formal parameters, docstrings, and lispref texi.
 This program is in the public domain.\n";
 
 die $usage if @ARGV;
-die $usage unless -r "src/alloc.c" && -d "CVS" && -d "lisp";
+die $usage unless -r "src/alloc.c" && -d ".bzr" && -d "lisp";
 
 my %texi_funtype;
 my %texi_arglist;
@@ -197,10 +197,8 @@ sub Check_function {
   Show_details $show_details, $function, "@parms", $docstring;
 }
 
-my $lisprefdir;
-if    (-d "man/lispref") { $lisprefdir = "man/lispref"; }
-elsif (-d "lispref") { $lisprefdir = "lispref"; }
-else { die "Can't find lispref texi directory.\n"; }
+my $lisprefdir = "doc/lispref";
+die "Can't find lispref texi directory.\n" unless -d $lisprefdir;
 
 open (FIND, "find $lisprefdir -name '*.texi' -print |") or die;
 while (my $file = <FIND>) {
diff --git a/admin/emacs-pretesters b/admin/emacs-pretesters
deleted file mode 100644
index 3b1270b477c..00000000000
--- a/admin/emacs-pretesters
+++ /dev/null
@@ -1,217 +0,0 @@
-Here are the guidelines for being an Emacs pretester.
-If you would like to do this, say so, and I'll add you to
-the pretest list.
-
-
-                  Information for Emacs Pretesters
-
-The purpose of Emacs pretesting is to verify that the new Emacs
-distribution, about to be released, works properly on your system *with
-no change whatever*, when installed following the precise
-recommendations that come with the Emacs distribution.
-
-Here are some guidelines on how to do pretesting so as to make it
-helpful.  All of them follow from common sense together with the
-nature of the purpose and the situation.
-
-Please save this file, and reread it when a new series of pretests
-starts.
-
-* Get the pretest from gnu/emacs/pretest/emacs-MM.0.NN.tar.gz
-on alpha.gnu.org.
-
-* After a few days of testing, if there are no problems, please report
-that Emacs works for you and what configuration you are testing it on.
-
-* If you want to communicate with other pretesters, send mail to
-emacs-pretesters@gnu.org.  I don't use that mailing list when I send
-to you because I've found that mailing lists tend to amplify random
-noise into long discussions or even arguments, and that can waste a
-lot of time.  But when you have a reason to ask other pretesters for
-help, you can do it that way.
-
-* It is absolutely vital that you report even the smallest change or
-departure from the standard sources and procedure.
-
-Otherwise, you are not testing the same program that we asked you to
-test.  Testing a different program is usually of no use whatever.  It
-can even cause trouble, if you fail to tell us that you tested some
-other program instead of what we are about to release.  We might think
-that Emacs works, when in fact it has not even been tried, and might
-have a glaring fault.
-
-* Don't use a site-load.el file or a site-init.el file when you pretest.
-Using either of those files means you are not testing Emacs as a typical
-site would use it.
-
-Actually, it does no harm to test Emacs with such customizations *as
-well as* testing it "out of the box".  Anything you do that could find
-a bug is useful, as long as you make sure we know exactly what you
-did.  The important point is that testing with local changes is no
-substitute for testing Emacs exactly as it is distributed.
-
-* Even changing the compilation options counts as a change in the
-program.  The Emacs sources specify which compilation options to use.
-Some of them are specified in makefiles, and some in machine-specific
-configuration files.  They also give you ways to override this--but if
-you do, then you are not testing what ordinary users will do.
-Therefore, when pretesting, it is vital to test with the default
-compilation options.
-
-(Testing with a different set of options can be useful *in addition*,
-but not *instead of* the default options.)
-
-* The machine and system configuration files of Emacs are parts of
-Emacs.  So when you test Emacs, you need to do it with the
-configuration files that come with Emacs.
-
-If Emacs does not come with configuration files for a certain machine,
-and you test it with configuration files that don't come with Emacs,
-this is effectively changing Emacs.  Because the crucial fact about
-the planned release is that, without changes, it doesn't work on that
-machine.
-
-To make Emacs work on that machine, we would need to install new
-configuration files.  That is not out of the question, since it is
-safe--it certainly won't break any other machines that already work.
-But you will have to rush in the legal papers to give the FSF
-permission to use such a large piece of text.
-
-* Look in the etc/MACHINES file.
-
-The etc/MACHINES file says which configuration files to use for your
-machine, so use the ones that are recommended.  If you guess, you might
-guess wrong and encounter spurious difficulties.  What's more, if you
-don't follow etc/MACHINES then you aren't helping to test that its
-recommendations are valid.
-
-The etc/MACHINES file may describe other things that you need to do
-to make Emacs work on your machine.  If so, you should follow these
-recommendations also, for the same reason.
-
-* Send your problem reports to bug-gnu-emacs@gnu.org.
-
-Sometimes we won't know what to do about a system-dependent issue, and
-we may need people to say what happens if you try a certain thing on a
-certain system.  When this happens, we'll send out a query.
-
-* Don't delay sending information.
-
-When you test on a system and encounter no problems, please report it
-right away.  That way, we will know that someone has tested Emacs on
-that kind of system.
-
-Please don't wait for several days "to see if it really works before
-you say anything."  Tell us right away that Emacs seems basically to
-work; then, if you notice a problem a few days later, tell us
-immediately about that when you see it.
-
-It is okay if you double check things before reporting a problem, such
-as to see if you can easily fix it.  But don't wait very long.  A good
-rule to use in pretesting is always to report every problem on the
-same day you encounter it, even if that means you can't find a
-solution before you report the problem.
-
-I'd much rather hear about a problem today and a solution tomorrow
-than get both of them tomorrow at the same time.
-
-* Make each bug report self-contained.
-
-If you refer back to another message, whether from you or from someone
-else, then it will be necessary for anyone who wants to investigate
-the bug to find the other message.  This may be difficult, it is
-probably time-consuming.
-
-To help save our time, simply copy the relevant parts of any previous
-messages into your own bug report.
-
-In particular, if we ask you for more information because a bug report
-was incomplete, it is best to send me the *entire* collection of
-relevant information, all together.  If you send just the additional
-information, that makes extra work for us.  There is even a risk that
-we won't remember what question you are sending the answer to.
-
-* When you encounter a bug that manifests itself as a Lisp error,
-try setting debug-on-error to t and making the bug happen again.
-Then you will get a Lisp backtrace.  Including that in your bug report
-is very useful.
-
-* For advice on debugging, see etc/DEBUG.
-
-* Debugging optimized code is possible, if you compile with GCC, but
-in some cases the optimized code can be confusing.  If you are not
-accustomed to that, recompile Emacs without -O.  One way to do this is
-
-    make clean
-    make CFLAGS=-g
-
-* Configure tries to figure out what kind of system you have by
-compiling and linking programs which calls various functions and looks
-at whether that succeeds.  The file config.log contains any messages
-produced by compilers while running configure, to aid debugging if
-configure makes a mistake.  But note that config.cache reads:
-
-# Giving --cache-file=/dev/null disables caching, for debugging configure.
-
-or more simply,
-
-rm config.cache
-./configure
-
-* Don't try changing Emacs *in any way* during pretest unless it fails
-to work unchanged.
-
-* Always be precise when talking about changes you have made.  Show
-things rather than describing them.  Use exact filenames (relative to
-the main directory of the distribution), not partial ones.  For
-example, say "I changed Makefile" rather than "I changed the
-makefile".  Instead of saying "I defined the MUMBLE macro", send a
-diff.
-
-* Always use `diff -c' to make diffs.  If you don't include context, it
-may be hard for us to figure out where you propose to make the
-changes.  So we might ignore your patch.
-
-* When you write a fix, keep in mind that we can't install a change
-that *might* break other systems without the risk that it will fail to
-work and therefore require an additional cycle of pretesting.
-
-People often suggest fixing a problem by changing config.h or
-src/Makefile to do something special that a particular system needs.
-Sometimes it is totally obvious that such changes would break Emacs
-for almost all users.  We can't possibly make a change like that.  All
-we can do is ask you to find a fix that is safe to install.
-
-Sometimes people send fixes that *might* be an improvement in
-general--but it is hard to be sure of this.  I can install such
-changes some of the time, but not during pretest, when I am trying to
-get a new version to work reliably as quickly as possible.
-
-The safest changes for us to install are changes to the s- and m-
-files.  At least those can't break other systems.
-
-Another safe kind of change is one that uses a conditional to make
-sure it will apply only to a particular kind of system.  Ordinarily,
-that is a bad way to solve a problem, and I would want to find a
-cleaner alternative.  But the virtue of safety can make it superior at
-pretest time.
-
-* Don't suggest changes during pretest to add features or make
-something cleaner.  Every change risks introducing a bug, so I won't
-install a change during pretest unless it is *necessary*.
-
-* If you would like to suggest changes for purposes other than fixing
-user-visible bugs, don't wait till pretest time.  Instead, send them
-after we have made a release that proves to be stable.  That is the
-easiest time to consider such suggestions.  If you send them at
-pretest time, we will have to defer them till later, and that might
-mean we forget all about them.
-
-* In some cases, if you don't follow these guidelines, your
-information might still be useful, but we would have to do more work
-to make use of it.  That might cause it to fall by the wayside.
-
-Local Variables:
-mode: text
-End:
-
diff --git a/admin/make-announcement b/admin/make-announcement
deleted file mode 100755
index 7d2482fc385..00000000000
--- a/admin/make-announcement
+++ /dev/null
@@ -1,87 +0,0 @@
-#! /bin/bash
-
-## Copyright (C) 2002-2013 Free Software Foundation, Inc.
-
-## Author: Francesco Potorti` <pot@gnu.org>
-
-## This file is part of GNU Emacs.
-
-## GNU Emacs is free software: you can redistribute it and/or modify
-## it under the terms of the GNU General Public License as published by
-## the Free Software Foundation, either version 3 of the License, or
-## (at your option) any later version.
-
-## GNU Emacs is distributed in the hope that it will be useful,
-## but WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-## GNU General Public License for more details.
-
-## You should have received a copy of the GNU General Public License
-## along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
-
-
-### Code:
-
-if [ $# -ne 2 ]; then
-    echo "usage: $0 <old version number> <new version number>" >&2
-    exit 1
-fi
-
-if [ ! -f INSTALL -o ! -f configure -o ! -d lib-src ]; then
-    echo "this script should be run in the emacs root directory" >&2
-    exit 2
-fi
-
-OLD=$1
-NEW=$2
-outfile=emacs-$NEW.announce
-oldtag=EMACS_PRETEST_$(echo $OLD|tr . _)
-newtag=EMACS_PRETEST_$(echo $NEW|tr . _)
-
-if [ -f $outfile ]; then
-    echo "$outfile exists"
-    echo -n "interrupt to abort, ENTER to overwrite "; read answer
-fi
-
-echo -n "tag name for OLD emacs version $OLD [$oldtag]: "; read answer
-if [ "$answer" ]; then oldtag=$answer; fi
-
-echo -n "tag name for NEW emacs version $NEW [$newtag]: "; read answer
-if [ "$answer" ]; then newtag=$answer; fi
-
-exec > $outfile
-
-cat <<EOF
-
-There is a new pretest available in
-
-  <ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-$NEW.tar.gz>
-
-Please report results from compiling and running the pretest to
-<bug-gnu-emacs@gnu.org>.  Your feedback is necessary for us
-to know on which platforms the pretest has been tried.
-
-If you have the tars from the previous pretest, and you have the
-\`xdelta' utility, you can instead download the much smaller
-
-  <ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-$OLD-$NEW.xdelta>
-
-You can use a command like
-
-  $ xdelta patch XDELTA PREVIOUS-TAR CURRENT-TAR
-
-to generate the new tar from the old one, where XDELTA is the xdelta
-file you downloaded, PREVIOUS-TAR is the tar file from the previous
-pretest, and CURRENT-TAR is the name of the tar file you downloaded.
-
-Information about xdelta can be found on the GNU ftp site, in
-/non-gnu/xdelta.README.
-
-Changes since $OLD
-
-EOF
-
-make-changelog-diff $oldtag $newtag
-
-echo " announcement created in $outfile" >&2
-
diff --git a/admin/make-changelog-diff b/admin/make-changelog-diff
deleted file mode 100755
index 88461131a3f..00000000000
--- a/admin/make-changelog-diff
+++ /dev/null
@@ -1,29 +0,0 @@
-#! /bin/bash
-
-## Author: Francesco Potorti` <pot@gnu.org>
-
-if [ $# -ne 2 ]; then
-    echo "usage: $0 TAG1 TAG2" >&2
-    exit 1
-fi
-
-if [ ! -f INSTALL -o ! -f configure -o ! -d lib-src ]; then
-    echo "this script should be run in the emacs root directory" >&2
-    exit 2
-fi
-
-cvs -q diff -b -r $1 -r $2 $(find -name ChangeLog|sort) |
-    sed -n -e 's/^=\+/======/p' -e 's/^> //p' -e 's/^diff.*//p' \
-        -e 's/^RCS file: .cvsroot.emacs.emacs.\(.*\),v/\1/p' |
-    sed -n -e "/^======$/ {
-                N
-                N
-                h
-                d
-               }
-               H
-               s/.*//
-               x
-               s/^\n//
-               p"
-
diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
index aa87f2694e6..573bb218c43 100644
--- a/admin/make-tarball.txt
+++ b/admin/make-tarball.txt
@@ -4,6 +4,9 @@ Instructions to create pretest or release tarballs.
 
 For each step, check for possible errors.
 
+0.  Decide on versions of automake and autoconf, and ensure you will
+    have them available for the duration of the release process.
+
 1.  `bzr update' (for a bound branch), or `bzr pull'.
      bzr status # check for locally modified files
 
@@ -11,13 +14,13 @@ For each step, check for possible errors.
     make sure that the later tagged version will bootstrap, should it be
     necessary to check it out.
 
-3.  Regenerate Emacs' etc/AUTHORS file (M-x load-file RET
-    lisp/emacs-lisp/authors.el RET, then M-x authors RET, then save
-    the *Authors* buffer).  This may require fixing syntactically
-    incorrect ChangeLog entries beforehand.
+3.  Regenerate the etc/AUTHORS file:
+    M-: (require 'authors) RET, M-x authors RET, save the *Authors* buffer.
+    If there are errors that relate to syntactically incorrect
+    ChangeLog entries, consider fixing them and repeating.
 
 4.  Set the version number (M-x load-file RET admin/admin.el RET, then
-    M-x set-version RET).  For a release, add released change log
+    M-x set-version RET).  For a release, add released ChangeLog
     entries (M-x add-release-logs RET).
 
     For a pretest, start at version .90.  After .99, use .990 (so that
@@ -46,9 +49,7 @@ For each step, check for possible errors.
     something like `find . | sort' in a clean bzr tree, and compare the
     results against the new tar contents.
 
-8.   xdelta delta emacs-OLD.tar.gz emacs-NEW.tar.gz emacs-OLD-NEW.xdelta
-
-9.   tar -zxf emacs-NEW.tar.gz; cd emacs-NEW
+8.   tar -zxf emacs-NEW.tar.gz; cd emacs-NEW
      ./configure && make && make -n install
     Use `script' or M-x compile to save the compilation log in
     compile-NEW.log and compare it against an old one.  The easiest way
@@ -56,7 +57,7 @@ For each step, check for possible errors.
     number of the old Emacs to __, do the same with the new log and do
     M-x ediff.  Especially check that Info files aren't built.
 
-10.  cd EMACS_ROOT_DIR; bzr tag TAG
+9.  cd EMACS_ROOT_DIR; bzr tag TAG
     TAG is emacs-XX.Y.ZZ for a pretest, emacs-XX.Y for a release.
 
     Shortly before the release, cut the version branch also, and open
@@ -64,11 +65,11 @@ For each step, check for possible errors.
     be sent to the emacs-diffs mailing list (by default, the list
     normally only gets commits to the trunk).
 
-11. Now you should upload the files to the GNU ftp server.  In order to
+10. Now you should upload the files to the GNU ftp server.  In order to
     do that, you must be registered as an Emacs maintainer and have your
     GPG key acknowledged by the ftp people.  For instructions, see
     http://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html
-    You can use the gnupload script to upload each FILE, like this:
+    You can use the gnulib script "gnupload" to upload each FILE, like this:
      gnupload --to alpha.gnu.org:emacs/pretest FILE (for a pretest)
      gnupload --to ftp.gnu.org:emacs FILE           (for a release)
 
@@ -84,16 +85,17 @@ For each step, check for possible errors.
     For a pretest, place the files in /incoming/alpha instead, so that
     they appear on ftp://alpha.gnu.org/.
 
-    For a release, upload a bz2 tarfile as well; this can save a lot
+    For a release, upload xz and bz2 tarfiles as well; this can save a lot
     of bandwidth.
 
-12. After five minutes, verify that the files are visible at
+11. After five minutes, verify that the files are visible at
     ftp://alpha.gnu.org/gnu/emacs/pretest/ for a pretest, at
     ftp://ftp.gnu.org/gnu/emacs/ for a release.
 
-13. For a pretest, announce it on emacs-devel and BCC the pretesters.
-    For a release, announce it on info-gnu@gnu.org,
-    info-gnu-emacs@gnu.org, and emacs-devel.
+12. For a pretest, announce it on emacs-devel and info-gnu-emacs@gnu.org.
+    For a release, also announce it on info-gnu@gnu.org.  (Probably
+    bcc the info- addresses to make it less likely that people will
+    followup on those lists.)
 
-14. For a release, update the Emacs homepage in the web repository.
+13. For a release, update the Emacs homepage in the web repository.
     Also add the new NEWS file as NEWS.xx.y.