Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

2 files changed, 114 insertions, 23 deletions

diff --git a/admin/notes/triage b/admin/notes/triage
new file mode 100644
index 00000000000..bc91b6c26f7
--- /dev/null
+++ b/admin/notes/triage
@@ -0,0 +1,68 @@
+HOW TO TRIAGE EMACS BUGS  -*- outline -*-
+
+This document just describes the procedure of triaging bugs, for information on
+how to work with the bug tracker, see the bugtracker file in this same directory
+for the basics.  You can also install the debbugs ELPA package for access to M-x
+debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs
+interface via org-mode.
+
+* Bug backlog triage procedure
+
+The goal of this triage is to prune down the list of old bugs, closing
+the ones that are not reproducible on the current release.
+
+  1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the
+     web browser), and accept the default list option of bugs that have severity
+     serious, important, or normal.
+  2. This will also show closed bugs that have yet to be archived.  You can
+     filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress).
+  3. For each bug, do the following:
+     - Read the mail thread for the bug.  Find out if anyone has been able to
+       reproduce this on the current release.
+     - If someone has been able to, then your work is finished for this bug.
+     - Make sure there's enough information to reproduce the bug.  It should be
+       very clear how to reproduce.  If not, please ask for specific steps to
+       reproduce.  If you don't get them, and you can't reproduce without them,
+       you can close as "doneunreproducible".
+     - If no one has mentioned being able to reproduce on the current release,
+       read the bug description and attempt to reproduce on an emacs started
+       with "emacs -Q" (the goal is to not let our personal configs interfere
+       with bug testing).
+     - If you can reproduce, then reply on the thread (either on the original
+       message, or anywhere you find appropriate) that you can reproduce this on
+       the current release. If your reproduction gives additional info (such as
+       a backtrace), then add that as well, since it will help whoever attempts
+       to fix it.
+     - If you can't reproduce, state that you can't reproduce it on the current
+       release, ask if they can try again against the current release.  Tag the
+       bug as "unreproducable".  Wait a few weeks for their reply - if they can
+       reproduce it, then that's great, otherwise close as "doneunreproducible".
+     - If the bug ends up still open, make sure the priority and other tags
+       seems reasonable.
+  4. Your changes will take some time to take effect.  After a period of minutes
+     to hours, you will get a mail telling you the control message has been
+     processed.  At this point, if there were no errors detected, you and
+     everyone else can see your changes. If there are errors, read the error
+     text - if you need help, consulting the bugtracker documentation in this
+     same directory.
+
+* New bug triage process
+
+The goal of the new bug triage process is similar to the backlog triage process,
+except that the focus is on prioritizing the bug, and making sure it is has
+necessary information for others to act on.
+
+For each new bug, ask the following questions:
+
+  1. Is the bug report written in a way to be easy to reproduce (starts from
+     emacs -Q, etc.)?  If not, ask the reporter to try and reproduce it on an
+     emacs without customization.
+  2. Is the bug report written against the lastest emacs?  If not, try to
+     reproduce on the latest version, and if it can't be reproduced, ask the
+     reporter to try again with the latest version.
+  3. Is the bug the same as another bug?  If so, merge the bugs.
+  4. What is the priority of the bug?  Add a priority: critical, grave, serious,
+     important, normal, minor, or wishlist.
+  5. Who should be the owner?  This depends on what component the bug is part
+     of.  You can look at the admin/MAINTAINERS file (then you can just search
+     emacs-devel to match the name with an email address).
diff --git a/admin/release-process b/admin/release-process
index 1cfcf544587..a6f9c2a19e0 100644
--- a/admin/release-process
+++ b/admin/release-process
@@ -10,18 +10,30 @@ The first phase of the release schedule is the "heads-down" working
 period for new features, on the `master' branch and several feature
 branches.
 
-** Phase two: bugfixes
+** Phase two: fixing and stabilizing the release branch
 
 Shortly before this phase, Emacs developers will be devoted to
 figuring out what features to include in the next release and what
 features to defer to a later release.
 
+This phase is mostly spent fixing bugs and documenting new features
+and changes on the "emacs-NN" branch.  Actually, the default branch
+for pushing any work in this phase should be "emacs-NN", except for
+new features.
+
 At the beginning of this phase, a release branch called "emacs-NN"
 ("NN" represents the major version number of the new Emacs release)
-will be cut from `master'.
-
-This phase is spent fixing bugs and eliminating undocumented new
-features on the "emacs-NN" branch.
+will be cut from `master'.  When that happens, the version number on
+`master' should be incremented; use admin/admin.el's `set-version'
+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).
 
 In parallel to this phase, `master' can receive new features, to be
 released in the next release cycle.  From time to time, the master
@@ -48,8 +60,16 @@ files.  See `admin/notes/years' for information about maintaining
 copyright years for GNU Emacs.
 
 ** Make sure the necessary sources and scripts for any generated files
-are included in the source tarfile.  (They don't need to be installed,
-so eg admin/ is fine.)
+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.)
+
+** 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.
 
 ** Manuals
 Check for node names using problematic characters:
@@ -60,7 +80,15 @@ Check for major new features added since the last release (e.g. new
 lisp files), and add the relevant authors to the Acknowledgments in
 doc/emacs/ack.texi and emacs.texi.
 
-Check cross-references between the manuals (eg from emacs to elisp)
+For major releases, rewrite the "Antinews" appendix of the User Manual
+(doc/emacs/anti.texi) to describe features lost by downgrading to the
+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.
+
+Check cross-references between the manuals (e.g. from emacs to elisp)
 are correct.  You can use something like the following in the info
 directory in the Emacs build tree:
 
@@ -78,32 +106,31 @@ Redirect /software/emacs/manual/html_node/automake/ /software/automake/manual/ht
 Another tool you can use to check links is gnu.org's linc.py:
 http://www.gnu.org/server/source/
 
-You run this something like:
+You run this with something like:
 
 cd /path/to/cvs/emacs-www
 linc.py -o /path/to/output-dir --url http://www.gnu.org/software/emacs/ .
 
 Be warned that it is really, really slow (as in, can take ~ a full day
 to check the manual/ directory).  It is probably best to run it on a
-single directory at a time from eg manual/html_node.  It is very
+single directory at a time from e.g. manual/html_node.  It is very
 inefficient, but may reveal a few things that info-xref does not.
 
-
 make emacs.dvi, elisp.dvi, and deal with any errors (undefined
 references etc) in the output.  Break any overfull lines.
 Underfull hboxes are not serious, but it can be nice to get rid of
 them if a simple rephrasing or rearrangement will work.
 
-Update the master menu and detailed menu (eg the antinews version).
+Update the master menu and detailed menu (e.g. the antinews version).
 The command texinfo-multiple-files-update can do this, but you
-probably want to apply the results selectively (eg the current master
+probably want to apply the results selectively (e.g. the current master
 menu has better line-breaks than the automatic version).  It includes
 the menu-entry name (if there is one) as well as the node name - using
 only the latter looks better.  Also, it doesn't seem to handle nested
 includes, so will miss edebug.texi etc.
 
 Check for widow and orphan lines in the printed manual; make sure all
-the pages really look ok in the manual as formatted.  Orphans/widows
+the pages really look OK in the manual as formatted.  Orphans/widows
 are cases where the first/last line of a paragraph is on its own at
 the end/start of a page, or where the last word in a paragraph is on
 its own at the start of a line.  It looks better if you reword/respace
@@ -117,9 +144,13 @@ pages of the manuals, and even if they do, the resulting page breaks
 depend on what paper and font size they use.  This also means that if
 you _are_ going to do this, it should be done with the paper and font
 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 eg 'make
+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
@@ -141,14 +172,6 @@ pt-br	Rodrigo Real
 ru      Alex Ott
 sk      Miroslav Vaško
 
-** For a major release, add a "New in Emacs XX" section to faq.texi.
-
-** Remove temporary +++/--- lines in NEWS.
-
-** Try to reorder NEWS: most important things first, related items together.
-
-** Consider bumping customize-changed-options-previous-release.
-
 ** cusver-check from admin.el can help find new defcustoms missing
 :version tags.