1 files changed, 32 insertions, 29 deletions

diff --git a/admin/release-process b/admin/release-process
index 2668ea3b445..28f2307846d 100644
--- a/admin/release-process
+++ b/admin/release-process
@@ -7,7 +7,7 @@ Each release cycle will be split into two periods.
 ** Phase one: development
 
 The first phase of the release schedule is the "heads-down" working
-period for new features, on the 'master' branch and several feature
+period for new features, on the 'master' branch and any needed feature
 branches.
 
 ** Phase two: fixing and stabilizing the release branch
@@ -29,47 +29,60 @@ command to do that, then commit the changes it made and push to
 'master'.  For major releases, also update the value of
 'customize-changed-options-previous-release'.
 
-The 2 main manuals, the User Manual and the Emacs Lisp Manual, need to
-be proofread, preferably by at least 2 different persons, and any
-uncovered problems fixed.  This is a lot of work, so it is advisable
-to divide the job between several people (see the checklist near the
-end of this file).
+Each chapter of the two main manuals, the User Manual and the Emacs
+Lisp Manual, should be proofread, preferably by at least two people.
+This job is so big that it should be considered a collective
+responsibility, not fobbed off on just a few people.  After each
+chapter is checked, mark off the name(s) of those who checked it in
+the checklist near the end of this file.
 
 In parallel to this phase, 'master' can receive new features, to be
 released in the next release cycle.  From time to time, the master
 branches merges bugfix commits from the "emacs-NN" branch.
+See admin/gitmerge.el.
 
 * RELEASE-CRITICAL BUGS
 
-Emacs uses the "blocking bug(s)" feature of Debbugs for bugs need to
-be addressed in the next release.
+Emacs uses the "blocking" feature of Debbugs for bugs that need to be
+addressed in the next release.
 
 Currently, bug#19759 is the tracking bug for release of 25.1 and
 bug#21966 is the tracking bug for release of 25.2.  Say bug#123 needs
+bug#21966 is the tracking bug for the next release.  Say bug#123 needs
 to be fixed for Emacs 25.1.  Send a message to control@debbugs.gnu.org
 that says:
 
    block 19759 by 123
 
-Change "block" to "unblock" to unblock the bug.
+Change "block" to "unblock" to remove a bug from the list.  Closed
+bugs are not listed as blockers, so you do not need to explicitly
+unblock one that has been closed.  You may need to force an update of
+the tracking bug with ctrl-f5/shift-reload to see the latest version.
+
 
 * TO BE DONE SHORTLY BEFORE RELEASE
 
-** Make sure the Copyright date reflects the current year in the source
-files.  See 'admin/notes/years' for information about maintaining
-copyright years for GNU Emacs.
+See 'admin/make-tarball.txt' for the details of making a release or pretest.
+
+** Make sure the Copyright date reflects the current year in all source files.
+(This should be done each January anyway, regardless of releases.)
+See admin/update-copyright and admin.el's set-copyright.
+For more details, see 'admin/notes/years'.
 
 ** Make sure the necessary sources and scripts for any generated files
 are included in the source tarball.  (They don't need to be installed,
-so e.g. admin/ is fine.)
-
-** Regenerate AUTHORS by using admin/authors.el
-(The instructions are at the beginning of that file.)
+so e.g. admin/ is fine.)  This is important for legal compliance.
 
 ** Remove temporary +++/--- lines in NEWS.
 But first make sure there are no unmarked entries, and update the
-documentation (or decide no updates are necessary) for those that
-aren't.
+documentation (or decide no updates are necessary) for those that aren't.
+
+** Try to reorder NEWS: most important things first, related items together.
+
+** For a major release, add a "New in Emacs XX" section to faq.texi.
+
+** cusver-check from admin.el can help find new defcustoms missing
+:version tags.
 
 ** Manuals
 Check for node names using problematic characters:
@@ -85,8 +98,7 @@ For major releases, rewrite the "Antinews" appendix of the User Manual
 previous version.  The way to do that is read NEWS, pick up the more
 significant changes and new features in the upcoming release, then
 describe the "benefits" from losing those features.  Be funny, use
-humor.  The text written for the previous major release can serve as
-good example.
+humor.  The text written for the previous releases can serve as an example.
 
 Check cross-references between the manuals (e.g. from emacs to elisp)
 are correct.  You can use something like the following in the info
@@ -147,10 +159,6 @@ size that the GNU Press are going to use when they print the manuals.
 I think this is different to what you get if you just use e.g. 'make
 emacs.pdf' (e.g., enable "smallbook").
 
-** Try to reorder NEWS: most important things first, related items together.
-
-** For a major release, add a "New in Emacs XX" section to faq.texi.
-
 ** Check the keybindings in the refcards are correct, and add any new ones.
 What paper size are the English versions supposed to be on?
 On Debian testing, the packages texlive-lang-czechslovak and
@@ -172,11 +180,6 @@ pt-br	Rodrigo Real
 ru      Alex Ott
 sk      Miroslav Vaško
 
-** cusver-check from admin.el can help find new defcustoms missing
-:version tags.
-
-** Add a line to etc/HISTORY for the release version number and date.
-
 * BUGS
 
 ** Check for modes which bind M-s that conflicts with a new global binding M-s