emacs-27 29708cb: Some precisions to bug handling

[Michael Albinus]

branch: emacs-27
commit 29708cbde7afef52458950512e91a7904ed491c9
Author: Michael Albinus <michael.albinus@gmx.de>
Commit: Michael Albinus <michael.albinus@gmx.de>

    Some precisions to bug handling
    
    * admin/admin.el (reminder-for-release-blocking-bugs): Add date to subject.
    
    * admin/notes/bug-triage:
    * admin/notes/bugtracker: Minor precisions.
---
 admin/admin.el         |  3 ++-
 admin/notes/bug-triage | 10 +++++++---
 admin/notes/bugtracker | 13 ++++++-------
 3 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/admin/admin.el b/admin/admin.el
index 93dc1f4..22d2967 100644
--- a/admin/admin.el
+++ b/admin/admin.el
@@ -951,7 +951,8 @@ changes (in a non-trivial way).  This function does not 
check for that."
      (lambda () ; posthook
        (goto-char (point-min))
        (mail-position-on-field "subject")
-       (insert (format "Release-blocking bugs for Emacs %s" version))
+       (insert (format "Reminder: release-blocking bugs for Emacs %s (%s)"
+                       version (format-time-string "%F" nil "UTC0")))
        (mail-text)
        (delete-region (point) (point-max))
        (insert "
diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage
index 87fb471..3d9a275 100644
--- a/admin/notes/bug-triage
+++ b/admin/notes/bug-triage
@@ -11,7 +11,11 @@ interface via org-mode.
 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
+  0. To start, check the most relevant bugs blocking a release by
+     calling debbugs-gnu-emacs-release-blocking-reports.  If you want
+     to check this for another Emacs version but the next-to-be-released-one,
+     use the "C-u" prefix.
+  1. After that, 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. For each bug, we want to primarily make sure it is still
@@ -20,7 +24,7 @@ the ones that are not reproducible on the current release.
      suggested checklist to follow for handling these bugs, along with
      example replies.  Closing, tagging, etc., are done
      with debbugs control messages, which in debbugs-gnu is initiated
-     with a "C".
+     with a "C" or "E".
      [ ] 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
@@ -87,7 +91,7 @@ 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 -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 latest emacs?  If not, try to
      reproduce on the latest version, and if it can't be reproduced, ask the
diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index ac54f8d..9eb65e1 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -33,7 +33,7 @@ By mailing commands to control@debbugs.gnu.org.  Place 
commands at the
 start of the message body, one per line.
 
 severity 123 serious|important|normal|minor|wishlist
-tags 123 moreinfo|unreproducible|wontfix|patch
+tags 123 moreinfo|unreproducible|wontfix|patch|notabug
 
 * More detailed information
 
@@ -185,7 +185,7 @@ Basically, reply only to the numbered bug address (and any 
individual
 people's addresses). Do not send mail direct to bug-gnu-emacs or
 emacs-pretest-bug unless you are reporting a new bug.
 
-** To close bug #123 (for example), send mail
+** To close bug#123 (for example), send mail
 
 To: 123-done@debbugs.gnu.org
 
@@ -260,7 +260,7 @@ reopen 123
 
 *** Bugs can be tagged in various ways (eg wontfix, patch, etc).
 The available tags are:
-patch wontfix moreinfo unreproducible fixed notabug security confirmed
+patch wontfix moreinfo unreproducible fixed notabug help security confirmed 
easy
 See https://debbugs.gnu.org/Developer#tags
 The list of tags can be prefixed with +, - or =, meaning to add (the
 default), remove, or reset the tags. E.g.:
@@ -290,10 +290,9 @@ limited, predefined set of normal tags are available (see 
above).
 
 2) A usertag is associated with a specific user.  This is normally
 an email address (with an "@" sign and least 4 characters after the "@"),
-but on debbugs.gnu.org, the definition is less strict - anything with
-5 or more alphanumeric characters will work.  For personal tags,
+but on debbugs.gnu.org, it can also be a package name.  For personal tags,
 using an email address is still recommended.  Please only use the
-"emacs" user, or other short users, for "official" tags.
+"emacs" user for "official" tags.
 
 You set usertags in the same way as tags, by talking to the control server.
 One difference is that you can also specify the associated user.
@@ -307,7 +306,7 @@ a) In a control message:
 user emacs      # or email@example.com
 usertags 1234 any-tag-you-like
 
-This will add a usertag "any-tag-you-like" to bug 1234.  The tag will
+This will add a usertag "any-tag-you-like" to bug#1234.  The tag will
 be associated with the user "emacs".  If you omit the first line,
 the tag will be associated with your email address.