Merge from trunk; up to 2014-02-23T23:41:17Z!lekktu@gmail.com.

13 files changed, 412 insertions, 38 deletions

diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index ee385f4dd75..7947b17973b 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -8,7 +8,8 @@ This is 95% of all you will ever need to know.
 
 ** How do I report a bug?
 Use M-x report-emacs-bug, or send mail to bug-gnu-emacs@gnu.org.
-If you want to Cc someone, use an "X-Debbugs-CC" header instead.
+If you want to Cc someone, use an "X-Debbugs-CC" header (or
+pseudo-header, see below) instead.
 
 ** How do I comment on a bug?
 Reply to a mail on the bug-gnu-emacs list in the normal way.
@@ -52,8 +53,8 @@ i) Your report will be assigned a number and generate an automatic reply.
 ii) Optionally, you can set some database parameters when you first
 report a bug (see "Setting bug parameters" below).
 
-iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
-see below).
+iii) If you want to CC: someone, use X-Debbugs-CC: (note this only
+applies to _new_ reports, not followups).
 
 Once your report is filed and assigned a number, it is sent out to the
 bug mailing list.  In some cases, it may be appropriate to just file a
@@ -92,18 +93,21 @@ 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
+** When reporting a new bug, to send a Cc to another address
 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
 Instead, use "X-Debbugs-CC:".  This ensures the Cc address will get a
 mail with the bug report number in.  If you do not do this, each reply
-in the subsequent discussion will end up creating a new bug.
-This is annoying.
+in the subsequent discussion might end up creating a new bug.
+This is annoying.  (So annoying that a form of message-id tracking has
+been implemented to hopefully stop this happening, but it is still
+better to use X-Debbugs-CC.)
 
-(So annoying that a form of message-id tracking has been implemented
-to hopefully stop this happening, but it is still better to use X-Debbugs-CC.)
+Like any X-Debbugs- header, this one can also be specified in the
+pseudo-header (see below), if your mail client does not let you add
+"X-" headers.
 
 If a new report contains X-Debbugs-CC in the input, this is
-converted to a real Cc header in the output.  (See Bug#1720).
+converted to a real Cc header in the output.  (See Bug#1780,5384)
 It is also merged into the Resent-CC header (see below).
 
 ** How does Debbugs send out mails?
@@ -218,8 +222,8 @@ Package: emacs
 Version: 23.0.60
 Severity: minor
 
-This can also include tags.  Some things (e.g. submitter) don't seem to
-work here.
+This can also include tags, or any X-Debbugs- setting.
+Some things (e.g. submitter) don't seem to work here.
 
 Otherwise, send mail to the control server, control@debbugs.gnu.org.
 At the start of the message body, supply the desired commands, one per
@@ -627,7 +631,9 @@ following headers:
 
 1) The leading envelope From line.
 2) Message-ID (get it from /var/log/mailman/vette).
-3) X-Debbugs-Envelope-To: submit
+3) X-Debbugs-Envelope-To: xxx
+For a new report, xxx = submit; for a control message, xxx = control;
+for a reply to bug#123, xxx = 123
 
 Then pipe it to receive as above.
 
diff --git a/admin/notes/bzr b/admin/notes/bzr
index f35ff95f9d6..a3a125cd675 100644
--- a/admin/notes/bzr
+++ b/admin/notes/bzr
@@ -316,3 +316,85 @@ When finished, use
   bzr bisect reset
 
 or simply delete the entire branch if you created it just for this.
+
+* Commit emails
+
+** Old method: bzr-hookless-email
+https://launchpad.net/bzr-hookless-email
+
+Runs hourly via cron.  Must ask Savannah admins to enable/disable it
+for each branch.  Stores the last revision that it mailed as
+last_revision_mailed in branch.conf on the server.  Breaks with bzr 2.6:
+
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00000.html
+
+Fix from https://bugs.launchpad.net/bzr-hookless-email/+bug/988195
+only partially works.  Breaks again on every merge commit:
+
+https://lists.ubuntu.com/archives/bazaar/2013q2/075520.html
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00024.html
+
+You can force it to skip the merge commit by changing the value for
+last_revision_mailed, eg:
+
+bzr config last_revision_mailed=xfq.free@gmail.com-20130603233720-u1aumaxvf3o0rlai -d bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/trunk/
+
+** New method: bzr-email plugin
+https://launchpad.net/bzr-email
+http://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00007.html
+
+Runs on commit.  Projects can enable it themselves by using `bzr
+config' to set post_commit_to option for a branch.  See `bzr help email'
+(if you have the plugin installed) for other options.
+
+The From: address will be that of your Savannah account, rather than
+your `bzr whoami' information.
+
+Note: if you have the bzr-email plugin installed locally, then when
+you commit to the Emacs repository it will also try to send a commit
+email from your local machine.  If your machine is not configured to
+send external mail, this will just fail.  In any case, you may prefer
+to either remove the plugin from your machine, or disable it for Emacs
+branches.  You can do this either by editing branch.conf in your Emacs
+branches, to override the server setting (untested; not sure this
+works), or by adding an entry to ~/.bazaar/locations.conf:
+
+  [bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/*/]
+  post_commit_to = ""
+
+You have to use locations.conf rather than bazaar.conf because the
+latter has a lower priority than branch.conf.
+
+* Using git-bzr
+
+** initially
+
+You can use Git locally to talk to the Bazaar repo as a "remote" repo
+via git-bzr (aka git-remote-bzr).  Initial clone:
+
+ git clone bzr::bzr+ssh://USER@bzr.sv.gnu.org/emacs/trunk e
+
+This creates the working dir e/ (with subdir .git, etc).  Disk usage
+is 13G (as of early 2014), so you will probably want to repack:
+
+ git repack -a -d -f --window=250 --depth=250 --window-memory=N
+
+where N is chosen to avoid swapping.  E.g., given 512MB RAM, N="200m"
+results in "du -sh .git" => 559M, about double the smallest reported
+value (obtained with "deprecated" command "git gc --aggressive").
+
+** steady-state
+
+Use "fetch", "pull" and other remote-to-local commands as usual.
+
+For "push", the Emacs Bazaar repo is configured with
+
+ append_revisions_only = True
+
+so some versions of git-remote-bzr may raise AppendRevisionsOnlyViolation
+(in func do_export) instead of displaying a "non fast-forward" message
+and skipping the branch.  See:
+
+ http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00436.html
+
+which includes a provisional patch to git-remote-bzr to do that.
diff --git a/admin/notes/changelogs b/admin/notes/changelogs
index 2e954570ce8..1025cfc217f 100644
--- a/admin/notes/changelogs
+++ b/admin/notes/changelogs
@@ -5,6 +5,8 @@ entry in their name, not yours.
 http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00793.html
   There is no need to make change log entries for files such as NEWS,
   MAINTAINERS, and FOR-RELEASE.
+"There is no need" means you don't have to, but you can if you want to.
+
 
 http://lists.gnu.org/archive/html/emacs-devel/2006-12/msg01135.html
   There is no need to indicate regeneration of files such as configure
diff --git a/admin/notes/commits b/admin/notes/commits
index 2c6f80c56f0..f33c6905d4c 100644
--- a/admin/notes/commits
+++ b/admin/notes/commits
@@ -45,6 +45,15 @@ Date: 	 Tue, 31 Mar 2009 12:21:20 +0900
     for modern source-control systems with a global log, it's better to
     have something like "Regenerate configure".
 
+(4) (Added in 2014) In commit comments, and ChangeLog files, it is best
+    to use ways of identifying revisions that are not dependent on a
+    particular version control system.  (At time of writing Emacs is
+    about to move to its fourth VCS and another move in the future is
+    not impossible.)  An excellent way to identify commits is by
+    quoting their summary line.  Another is with an action stamp - an
+    RFC3339 date followed by ! followed by the committer's email - for
+    example, "2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my
+    previous commit" will suffice.
 
 Followup discussion:
 http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html
diff --git a/admin/notes/copyright b/admin/notes/copyright
index 3a404b69678..a54bcb6108b 100644
--- a/admin/notes/copyright
+++ b/admin/notes/copyright
@@ -1,4 +1,4 @@
-Copyright (C) 2007-2013 Free Software Foundation, Inc.
+Copyright (C) 2007-2014 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
diff --git a/admin/notes/elpa b/admin/notes/elpa
index db14456fe32..469a0ca8bd1 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -1,24 +1,21 @@
 NOTES ON THE EMACS PACKAGE ARCHIVE
 
-The GNU Emacs package archive, at elpa.gnu.org, is managed using a Bzr
-branch named "elpa", hosted on Savannah.  To check it out:
+The GNU Emacs package archive, at elpa.gnu.org, is managed using a Git
+repository named "elpa", hosted on Savannah.  To check it out:
 
-  bzr branch bzr+ssh://USER@bzr.savannah.gnu.org/emacs/elpa elpa
+  git clone git://bzr.sv.gnu.org/emacs/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
+  git remote set-url --push origin git+ssh://bzr.sv.gnu.org/srv/git/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.
+Changes to this branch propagate to elpa.gnu.org via a "deployment" script run
+daily.  This script (which is kept in elpa/admin/update-archive.sh) 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.)
+A new package is released as soon as the "version number" of that package is
+changed.  So you can use `elpa' to work on a package without fear of releasing
+those changes prematurely.  And once the code is ready, just bump the
+version number to make a new release of the package.
 
 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/font-backend b/admin/notes/font-backend
index cdf2001580d..5c36cf08c62 100644
--- a/admin/notes/font-backend
+++ b/admin/notes/font-backend
@@ -1,4 +1,4 @@
-Copyright (C) 2002-2013 Free Software Foundation, Inc.
+Copyright (C) 2002-2014 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
diff --git a/admin/notes/hydra b/admin/notes/hydra
new file mode 100644
index 00000000000..3b6bc87a2f6
--- /dev/null
+++ b/admin/notes/hydra
@@ -0,0 +1,66 @@
+-*- outline -*-
+
+Copyright (C) 2013-2014 Free Software Foundation, Inc.
+See the end of the file for license conditions.
+
+NOTES FOR EMACS CONTINUOUS BUILD ON HYDRA
+
+A continuous build for Emacs can be found at
+http://hydra.nixos.org/jobset/gnu/emacs-trunk
+http://hydra.nixos.org/jobset/gnu/emacs-24
+
+* It builds Emacs on various platforms.
+Sometimes jobs fail due to hydra problems rather than Emacs problems.
+Eg it seems like the cygwin build will never work again.
+http://lists.gnu.org/archive/html/hydra-users/2013-08/msg00000.html
+
+* Mail notifications
+In addition to the web interface, Hydra can send notifications by
+email when the build status of a project changes—e.g., from
+`SUCCEEDED' to `FAILED'.  It sends notifications about build status in
+Emacs trunk to emacs-buildstatus@gnu.org.
+
+If you want to receive these notifications, please subscribe at
+http://lists.gnu.org/mailman/listinfo/emacs-buildstatus
+
+* The Emacs jobset consists of the following jobs:
+
+** The `tarball' job
+which gets a checkout from bzr, and does a bootstrap followed
+by running make-dist to create a tarball.  If this job fails, all the
+others will too (because they use the tarball as input).
+
+** The `build' job
+which starts from the tarball and does a normal build
+
+** The 'coverage' job
+does a gcov build and then runs `make check'.  Fails if any test fails.
+
+* Nix expressions
+The recipe for GNU Emacs are available via Git:
+http://git.savannah.gnu.org/cgit/hydra-recipes.git/tree/emacs
+
+To modify the build job, email the patch to hydra-users@gnu.org.  The
+build recipes are written in the Nix language.
+
+* Other Information
+For a list of other GNU packages that have a continuous build on
+Hydra, see http://hydra.nixos.org/project/gnu
+
+See http://www.gnu.org/software/devel.html#Hydra for more information.
+
+
+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/>.
diff --git a/admin/notes/lel-TODO b/admin/notes/lel-TODO
index 2c6d86a4ffd..4a4ccb5e6e8 100644
--- a/admin/notes/lel-TODO
+++ b/admin/notes/lel-TODO
@@ -1,6 +1,6 @@
 Some lisp/emacs-lisp/ Features and Where They Are Documented
 
-Copyright (C) 2007-2013 Free Software Foundation, Inc.
+Copyright (C) 2007-2014 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 
diff --git a/admin/notes/multi-tty b/admin/notes/multi-tty
index c4edd3abc93..dff788351a9 100644
--- a/admin/notes/multi-tty
+++ b/admin/notes/multi-tty
@@ -1,6 +1,6 @@
 -*- coding: utf-8; mode: text; -*-
 
-Copyright (C) 2007-2013 Free Software Foundation, Inc.
+Copyright (C) 2007-2014 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 From README.multi-tty in the multi-tty branch.
diff --git a/admin/notes/unicode b/admin/notes/unicode
index 21704c78a00..654580639f7 100644
--- a/admin/notes/unicode
+++ b/admin/notes/unicode
@@ -1,6 +1,6 @@
-                                            -*-mode: text; coding: latin-1;-*-
+                                            -*-mode: text; coding: utf-8;-*-
 
-Copyright (C) 2002-2013 Free Software Foundation, Inc.
+Copyright (C) 2002-2014 Free Software Foundation, Inc.
 See the end of the file for license conditions.
 
 Problems, fixmes and other unicode-related issues
@@ -12,9 +12,9 @@ regard to completeness.
 
  * SINGLE_BYTE_CHAR_P returns true for Latin-1 characters, which has
    undesirable effects.  E.g.:
-   (multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
-   (multibyte-string-p (concat [?£])) => nil
-   (text-char-description ?£) => "M-#"
+   (multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
+   (multibyte-string-p (concat [?£])) => nil
+   (text-char-description ?£) => "M-#"
 
         These examples are all fixed by the change of 2002-10-14, but
         there still exist questionable SINGLE_BYTE_CHAR_P in the
@@ -77,7 +77,7 @@ regard to completeness.
    spelling and calendar, but that's not a Unicode issue.)
 
  * Handle Unicode combining characters usefully, e.g. diacritics, and
-   handle more scripts specifically (à la Devanagari).  There are
+   handle more scripts specifically (à la Devanagari).  There are
    issues with canonicalization.
 
  * We need tabular input methods, e.g. for maths symbols.  (Not
@@ -98,6 +98,134 @@ regard to completeness.
  * Old auto-save files, and similar files, such as Gnus drafts,
    containing non-ASCII characters probably won't be re-read correctly.
 
+
+Source file encoding
+--------------------
+
+Most Emacs source files are encoded in UTF-8 (or in ASCII, which is a
+subset), but there are a few exceptions, listed below.  Perhaps
+someday many of these files will be converted to UTF-8, for
+convenience when using tools like 'grep -r', but this might need
+nontrivial changes to the build process.
+
+ * chinese-big5
+
+     These are verbatim copies of files taken from external sources.
+     They haven't been converted to UTF-8.
+
+        leim/CXTERM-DIC/4Corner.tit
+        leim/CXTERM-DIC/ARRAY30.tit
+        leim/CXTERM-DIC/ECDICT.tit
+        leim/CXTERM-DIC/ETZY.tit
+        leim/CXTERM-DIC/PY-b5.tit
+        leim/CXTERM-DIC/Punct-b5.tit
+        leim/CXTERM-DIC/QJ-b5.tit
+        leim/CXTERM-DIC/ZOZY.tit
+        leim/MISC-DIC/CTLau-b5.html
+        leim/MISC-DIC/cangjie-table.b5
+
+ * chinese-iso-8bit
+
+     These are verbatim copies of files taken from external sources.
+     They haven't been converted to UTF-8.
+
+        leim/CXTERM-DIC/CCDOSPY.tit
+        leim/CXTERM-DIC/Punct.tit
+        leim/CXTERM-DIC/QJ.tit
+        leim/CXTERM-DIC/SW.tit
+        leim/CXTERM-DIC/TONEPY.tit
+        leim/MISC-DIC/pinyin.map
+        leim/MISC-DIC/CTLau.html
+        leim/MISC-DIC/ziranma.cin
+
+ * cp850
+
+     This file contains non-ASCII characters in unibyte strings.  When
+     editing a keyboard layout it's more convenient to see 'é' than
+     '\202', and the MS-DOS compiler requires the single byte if a
+     backslash escape is not being used.
+
+        src/msdos.c
+
+ * iso-2022-cn-ext
+
+     This file is externally generated from leim/MISC-DIC/cangjie-table.b5
+     by Big5->CNS converter.  It hasn't been converted to UTF-8.
+
+        leim/MISC-DIC/cangjie-table.cns
+
+ * iso-latin-2
+
+     These files are processed by csplain, a program that requires
+     Latin-2 input.  In 2012 the csplain maintainers started
+     recommending UTF-8, but these files haven't been converted yet.
+
+        etc/refcards/cs-dired-ref.tex
+        etc/refcards/cs-refcard.tex
+        etc/refcards/cs-survival.tex
+        etc/refcards/sk-dired-ref.tex
+        etc/refcards/sk-refcard.tex
+        etc/refcards/sk-survival.tex
+
+ * japanese-iso-8bit
+
+     SKK-JISYO.L is a verbatim copy of a file taken from an external source.
+     It hasn't been converted to UTF-8.
+
+        leim/SKK-DIC/SKK-JISYO.L
+
+ * japanese-shift-jis
+
+     This is a verbatim copy of a file taken from an external source.
+     It hasn't been converted to UTF-8.
+
+        admin/charsets/mapfiles/cns2ucsdkw.txt
+
+ * no-conversion
+
+     This file purposely contains arbitrary bytes interspersed within text,
+     to test whether the Emacs distribution is corrupted.
+
+        lib-src/testfile
+
+ * iso-2022-7bit
+
+     This file switches between CJK charsets, which is not encoded in UTF-8.
+
+        etc/HELLO
+
+     Each of these files contains just one CJK charset, but Emacs
+     currently has no easy way to specify set-charset-priority on a
+     per-file basis, so converting any of these files to UTF-8 might
+     change the file's appearance when viewed by an Emacs that is
+     operating in some other language environment.
+
+        etc/tutorials/TUTORIAL.ja
+        leim/quail/cyril-jis.el
+        leim/quail/hanja-jis.el
+        leim/quail/japanese.el
+        leim/quail/py-punct.el
+        leim/quail/pypunct-b5.el
+        lisp/international/ja-dic-cnv.el
+        lisp/international/ja-dic-utl.el
+        lisp/international/kinsoku.el
+        lisp/international/kkc.el
+        lisp/international/titdic-cnv.el
+        lisp/language/japan-util.el
+        lisp/language/japanese.el
+        lisp/term/x-win.el
+
+ * utf-8-emacs
+
+     These files contain characters that cannot be encoded in UTF-8.
+
+        leim/quail/tibetan.el
+        leim/quail/ethiopic.el
+        lisp/international/titdic-cnv.el
+        lisp/language/tibetan.el
+        lisp/language/tibet-util.el
+        lisp/language/ind-util.el
+
 
 This file is part of GNU Emacs.
 
diff --git a/admin/notes/www b/admin/notes/www
new file mode 100644
index 00000000000..4d092ca7fa0
--- /dev/null
+++ b/admin/notes/www
@@ -0,0 +1,82 @@
+-*- outline -*-
+
+Copyright (C) 2013-2014 Free Software Foundation, Inc.
+See the end of the file for license conditions.
+
+NOTES FOR EMACS WWW PAGES
+
+* Renaming pages, redirects
+
+Sometimes you want to move a page to a new location.
+If the old location might be referenced somewhere else, you should add
+some form of redirect to the new location.  There are several ways to
+do this:
+
+** Use a refresh directive in the old file
+https://www.gnu.org/server/standards/README.webmastering.html#htaccess
+
+Change the entire contents of the old file to be something like:
+
+<meta http-equiv="refresh" content="0; url=/software/emacs/manual/elisp.html">
+
+I can't think of any reason to use this method.
+
+** Use a .symlinks file
+https://www.gnu.org/server/standards/README.webmastering.html#symlinks
+
+This is really an interface to mod_rewrite rules, but it acts like
+symlinks.  Remove old-page.html altogether, and create a ".symlinks"
+file in the relevant directory, with contents of the form:
+
+  # This is a comment line.
+  old-page.html new-page.html
+
+Anyone visiting old-page.html will be shown the contents of new-page.html.
+Note that changes to .symlinks file are only updated periodically on
+the server via cron (twice an hour?).  So there will be a delay (of up
+to 30 minutes?) before you see your changes take effect.
+
+This method is ok, but:
+i) a person visiting old-page.html has no idea that the page has moved.
+They still see old-page.html in their address bar.  (In other words,
+the mod_rewrite rule does not use the [R] flag.)  Sometimes this is
+what you want, sometimes not.
+
+ii) it doesn't work right if the new page is in a different directory
+to the old page: relative links from the visited page will break.
+
+** Use a .htaccess file
+
+Remove old-page.html altogether, and create a ".htaccess" file in the
+relevant directory, with contents of the form:
+
+  # This is a comment line.
+  Redirect 301 /software/emacs/old-page.html /software/emacs/dir/new-page.html
+
+Use "301" for a permanent redirection, otherwise you can omit the number.
+Note that paths must (?) be relative to the top-level www.gnu.org.
+
+I think this is the best method.  You can specify temporary or
+permanent redirects, and changes go live more-or-less straight away.
+
+This method is useful for making cross-references to non-Emacs manuals
+work; see manual/.htaccess in the repository.  You only have to add a
+single redirect for every given external manual, you can redirect
+html_node to hmtl_node and html_mono to html_mono.
+
+
+
+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/>.
diff --git a/admin/notes/years b/admin/notes/years
index e6b38c5aefd..342fe9e2307 100644
--- a/admin/notes/years
+++ b/admin/notes/years
@@ -2,6 +2,8 @@ HOW TO MAINTAIN COPYRIGHT YEARS FOR GNU EMACS
 
 Maintaining copyright years is now very simple: every time a new year
 rolls around, add that year to every FSF (and AIST) copyright notice.
+Do this by running the 'admin/update-copyright' script on a fresh bzr
+checkout.  Inspect the results for plausibility, then commit them.
 
 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.
@@ -28,10 +30,10 @@ but should keep the full list in a comment in the source.
  since Emacs 21 came out in 2001, all the subsequent years[1].  We don't
  need to check whether *that file* was changed in those years.
  It's sufficient that *Emacs* was changed in those years (and it was!).
-  
+
  For those files that have been added since then, we should add
  the year it was added to Emacs, and all subsequent years."
-  
+
  --RMS, 2005-07-13
 
 [1] Note that this includes 2001 - see