]> code.delx.au - gnu-emacs/blobdiff - admin/notes/bugtracker
Merge from origin/emacs-25
[gnu-emacs] / admin / notes / bugtracker
index f2805eae44392265bf4d5f8186e42288d9f968d9..3d6df03d5e717148faf54fbb97e7d004a8732388 100644 (file)
@@ -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.
 
 ** 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.
 
 ** 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).
 
 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
 
 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
@@ -63,13 +64,16 @@ quiet@debbugs.gnu.org.
 ** How do I reply to an existing bug report?
 Reply to 123@debbugs.gnu.org, replacing 123 with the number
 of the bug you are interested in.  NB this only sends mail to the
 ** How do I reply to an existing bug report?
 Reply to 123@debbugs.gnu.org, replacing 123 with the number
 of the bug you are interested in.  NB this only sends mail to the
-bug-list, it does NOT (?) send a CC to the original bug submitter.
+bug-list, it does NOT send a CC to the original bug submitter.
 So you need to explicitly CC him/her (and anyone else you like).
 So you need to explicitly CC him/her (and anyone else you like).
+(This works the same way as all the Emacs mailing lists.  We generally
+don't assume anyone who posts to a list is subscribed to it, so we
+cc everyone on replies.)
 
 (Many people think the submitter SHOULD be automatically subscribed
 to subsequent discussion, but this does not seem to be implemented.
 
 (Many people think the submitter SHOULD be automatically subscribed
 to subsequent discussion, but this does not seem to be implemented.
-See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
-See also http://debbugs.gnu.org/5439
+See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078
+See also http://debbugs.gnu.org/5439 )
 
 Do NOT send a separate copy to the bug list address, since this may
 generate a new report.  The only time to send mail to the bug list
 
 Do NOT send a separate copy to the bug list address, since this may
 generate a new report.  The only time to send mail to the bug list
@@ -85,22 +89,25 @@ The "owner@debbugs.gnu.org" entry is there because it appears in the
 "Resent-To" header.  For a long time Rmail erroneously included such
 headers in replies.  If you correspond with an Rmail user on a bug,
 these addresses may end up in the Cc.  Mailing to them does nothing
 "Resent-To" header.  For a long time Rmail erroneously included such
 headers in replies.  If you correspond with an Rmail user on a bug,
 these addresses may end up in the Cc.  Mailing to them does nothing
-but create duplicates and errors.  (It is possible you might want to
-have a dialog with the owner address, outside of normal bug
-reporting.)
+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
 (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
 
 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?
 It is also merged into the Resent-CC header (see below).
 
 ** How does Debbugs send out mails?
@@ -122,7 +129,7 @@ Resent-CC:   maintainer email address, plus any X-Debbugs-CC: entries
 
 The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
 
 
 The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
 
-** To not get acknowledgement mail from the tracker,
+** To not get acknowledgment mail from the tracker,
 add an "X-Debbugs-No-Ack:" header (with any value).  If you use Gnus,
 you can add an element to gnus-posting-styles to do this automatically, eg:
 
 add an "X-Debbugs-No-Ack:" header (with any value).  If you use Gnus,
 you can add an element to gnus-posting-styles to do this automatically, eg:
 
@@ -133,8 +140,7 @@ you can add an element to gnus-posting-styles to do this automatically, eg:
 
 ** To record a bug in the tracker without sending mail to the bug list.
 This can be useful to make a note of something discussed on
 
 ** To record a bug in the tracker without sending mail to the bug list.
 This can be useful to make a note of something discussed on
-emacs-devel that needs fixing.  In other words, this can be the
-equivalent of adding something to FOR-RELEASE.
+emacs-devel that needs fixing.
 
 To: quiet@debbugs.gnu.org
 [headers end]
 
 To: quiet@debbugs.gnu.org
 [headers end]
@@ -215,8 +221,8 @@ Package: emacs
 Version: 23.0.60
 Severity: minor
 
 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
 
 Otherwise, send mail to the control server, control@debbugs.gnu.org.
 At the start of the message body, supply the desired commands, one per
@@ -267,32 +273,35 @@ to a bug.  There are two differences between normal tags and user tags:
 1) Anyone can define any valid usertag they like.  In contrast, only a
 limited, predefined set of normal tags are available (see above).
 
 1) Anyone can define any valid usertag they like.  In contrast, only a
 limited, predefined set of normal tags are available (see above).
 
-2) A usertag is associated with a specific email address.
+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,
+using an email address is still recommended.  Please only use the
+"emacs" user, or other short users, 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
-email address.  If you don't explicitly specify an address, then it
-will use the one from which you send the control message. The address
-must have the form of an email address (with an "@" sign and least 4
-characters after the "@").
+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.
+If you don't explicitly specify a user, then it will use the email
+address from which you send the control message.
 
 *** Setting usertags
 
 a) In a control message:
 
 
 *** Setting usertags
 
 a) In a control message:
 
-user bug-gnu-emacs@gnu.org
+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
 usertags 1234 any-tag-you-like
 
 This will add a usertag "any-tag-you-like" to bug 1234.  The tag will
-be associated with the address "bug-gnu-emacs@gnu.org".  If you omit
-the first line, the tag will be associated with your email address.
+be associated with the user "emacs".  If you omit the first line,
+the tag will be associated with your email address.
 
 The syntax of the usertags command is the same as that of tags (eg wrt
 the optional [=+-] argument).
 
 b) In an initial submission, in the pseudo-header:
 
 
 The syntax of the usertags command is the same as that of tags (eg wrt
 the optional [=+-] argument).
 
 b) In an initial submission, in the pseudo-header:
 
-User: bug-gnu-emacs@gnu.org
+User: emacs
 Usertags: a-new-tag
 
 Again, the "User" is optional.
 Usertags: a-new-tag
 
 Again, the "User" is optional.
@@ -309,7 +318,7 @@ http://debbugs.gnu.org/cgi/pkgindex.cgi?indexon=users
 
 **** To find all bugs usertagged by a given email address:
 
 
 **** To find all bugs usertagged by a given email address:
 
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs
 
 (Supposedly, the "users" field can be a comma-separated list of more
 than one email address, but it does not seem to work for me.)
 
 (Supposedly, the "users" field can be a comma-separated list of more
 than one email address, but it does not seem to work for me.)
@@ -319,12 +328,12 @@ than one email address, but it does not seem to work for me.)
 This works just like a normal tags search, but with the addition of a
 "users" field.  Eg:
 
 This works just like a normal tags search, but with the addition of a
 "users" field.  Eg:
 
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=calendar
 
 *** To merge bugs:
 Eg when bad replies create a bunch of new bugs for the same report.
 Bugs must all be in the same state (e.g. same package(s) and severity
 
 *** To merge bugs:
 Eg when bad replies create a bunch of new bugs for the same report.
 Bugs must all be in the same state (e.g. same package(s) and severity
--- see `reassign' and `severity' below), but need not have the same
+-- see 'reassign' and 'severity' below), but need not have the same
 tags (tags are merged). E.g.:
 
 merge 123 124 125 ...
 tags (tags are merged). E.g.:
 
 merge 123 124 125 ...
@@ -333,8 +342,8 @@ Note that merging does not affect titles.  In particular, a "retitle"
 of merged bugs only affects individual bugs, not all of them.
 
 *** Forcing a merge:
 of merged bugs only affects individual bugs, not all of them.
 
 *** Forcing a merge:
-Like `merge', but bugs need not be in the same state.  The packages
-must still match though (see `reassign' below).  The first one listed
+Like 'merge', but bugs need not be in the same state.  The packages
+must still match though (see 'reassign' below).  The first one listed
 is the master.  E.g.:
 
 forcemerge 123 124 125 ...
 is the master.  E.g.:
 
 forcemerge 123 124 125 ...
@@ -373,7 +382,7 @@ See http://debbugs.gnu.org/Developer#severities for the meanings.
 *** To set the owner of a bug:
 owner 123 A Hacker <none@example.com>
 
 *** To set the owner of a bug:
 owner 123 A Hacker <none@example.com>
 
-The shorthand `!' means your own address.
+The shorthand '!' means your own address.
 
 *** To remove the owner of a bug:
 noowner 123
 
 *** To remove the owner of a bug:
 noowner 123
@@ -398,7 +407,7 @@ reassign 1234 emacs
 Note that reassigning clears the list of found versions, even if the
 new packages includes the original one.
 
 Note that reassigning clears the list of found versions, even if the
 new packages includes the original one.
 
-** To remove spam from the tracker, move it to the `spam' pseudo-package:
+** To remove spam from the tracker, move it to the 'spam' pseudo-package:
 reassign 123 spam
 
 (Should not be necessary any more, now that the input is moderated.)
 reassign 123 spam
 
 (Should not be necessary any more, now that the input is moderated.)
@@ -453,68 +462,30 @@ time, rather than by increasing bug number
 
 "raw" = ?
 
 
 "raw" = ?
 
-** ChangeLog issues
+** Change log issues
 
 *** When you fix a bug, it can be helpful to put the bug number in the
 
 *** When you fix a bug, it can be helpful to put the bug number in the
-ChangeLog entry, for example:
+change log entry, for example:
 
 
-   * foo.el (foofunc): Fix the `foo' case.  (Bug#123)
+   * lisp/menu-bar.el (menu-set-font): Doc fix.  (Bug#21303)
 
 Then the relevant bug can be found for easy reference.  If it's an
 
 Then the relevant bug can be found for easy reference.  If it's an
-obvious fix (e.g. a typo), there's no need to clutter the log with the
+obvious fix (e.g., a typo), there's no need to clutter the log with the
 bug number.
 
 Similarly, when you close a bug, it can be helpful to include the
 bug number.
 
 Similarly, when you close a bug, it can be helpful to include the
-relevant ChangeLog entry in the message to the bug tracker, so people
+relevant change log entry in the message to the bug tracker, so people
 can see exactly what the fix was.
 
 *** bug-reference-mode
 
 can see exactly what the fix was.
 
 *** bug-reference-mode
 
-Activate `bug-reference-mode' in ChangeLogs to get clickable links to
+Activate 'bug-reference-mode' in ChangeLogs to get clickable links to
 the bug web-pages.
 
 *** Debian stuff
 
 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
 
 the bug web-pages.
 
 *** Debian stuff
 
 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
 
-** Bazaar stuff
-
-*** You can use `bzr commit --fixes debbugs:123' to mark that a commit fixes
-Emacs bug 123.  You will first need to add a line to one of your
-configuration files, ~/.bazaar/bazaar.conf or ~/.bazaar/locations.conf:
-
-bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
-
-Here "{id}" is a literal string, a placeholder that will be replaced
-by the bug number you specify after `--fixes debbugs:' in the bzr
-command line (123 in the example above).
-
-In the bazaar.conf file, this setting should go into the [DEFAULT]
-section.
-
-In the locations.conf file, it should go into the branch-specific
-configuration section for the branch where you want this to be in
-effect.  For example, if you want this to be in effect for the branch
-located at `/home/projects/emacs/trunk', you need to have this in your
-~/.bazaar/locations.conf file:
-
-[/home/projects/emacs/trunk]
-bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
-
-If you want to use this in all Emacs branches whose common parent is
-`/home/projects/emacs', put the setting in the [/home/projects/emacs]
-section.  See "bzr help configuration" for more information about
-the *.conf files, their location and formats.  See "bzr help bugs" for
-more information about the bugtracker_debbugs_url setting.
-
-See also log-edit-rewrite-fixes in .dir-locals.el.
-
-Note that all this does is add some metadata to the commit, it doesn't
-actually mark the bug as closed in the tracker.  You can see this
-information with `bzr log', and it will show up as a link in a recent
-loggerhead installation, or with some of the graphical frontends to
-`bzr log'.
-
 ** Gnus-specific voodoo
 
 *** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
 ** Gnus-specific voodoo
 
 *** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
@@ -607,7 +578,7 @@ An /etc/aliases entry redirects it to the real emacs-bug-tracker address.
 All discarded messages are stored in /var/lib/mailman/spam.
 If a non-spam message accidentally gets discarded, just do:
 
 All discarded messages are stored in /var/lib/mailman/spam.
 If a non-spam message accidentally gets discarded, just do:
 
-cat /var/lib/mailman/spam/not-really-spam.msg | /usr/lib/debbugs/receive
+/usr/lib/debbugs/receive < /var/lib/mailman/spam/not-really-spam.msg
 chown Debian-debbugs:Debian-debbugs /var/lib/debbugs/spool/incoming/*
 ... check it works ...
 mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
 chown Debian-debbugs:Debian-debbugs /var/lib/debbugs/spool/incoming/*
 ... check it works ...
 mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
@@ -615,6 +586,18 @@ mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
 Also check that the sender was not added to the auto-discard/reject list
 in the debbugs-submit Mailman interface.
 
 Also check that the sender was not added to the auto-discard/reject list
 in the debbugs-submit Mailman interface.
 
+If you don't have the actual mail, just the mailman moderation mail
+version of it, you need to extract the original mail, and add the
+following headers:
+
+1) The leading envelope From line.
+2) Message-ID (get it from /var/log/mailman/vette).
+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.
+
 ** Administrivia
 
 The debbugs-submit list should have the administrivia option off,
 ** Administrivia
 
 The debbugs-submit list should have the administrivia option off,
@@ -629,3 +612,22 @@ mytest       my.email.address
 
 Then if you do all your testing with 'Package: mytest', the resulting
 mails should only go to your email address.
 
 Then if you do all your testing with 'Package: mytest', the resulting
 mails should only go to your email address.
+
+** Adding new tags
+
+Add them to @gTags in /etc/debbugs/config.
+I think you also have to add them to 'tags' and 'tags_single_letter'
+in /usr/share/perl5/Debbugs/Config.pm.
+And update /var/www/Developer.html with a description of what the tag means.
+And the "valid tags" list in /var/www/index.html.
+
+** Backups
+
+The FSF sysadmins handle multi-generational backups of the filesystem
+on debbugs.gnu.org.  But if you really want to have your own backup of
+the bug database, you can use rsync (this requires login access to
+debbugs.gnu.org):
+
+ rsync -azvv -e ssh USER@debbugs.gnu.org:/var/lib/debbugs/ DEST
+
+Note that this occupies well over 1G of disk space.