[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

New bugs features - debian-bugs-forwarded, debian-bugs-quiet



Two new debian-bugs features are now available:

1. You can mark a bug report as `forwarded to the upstream
maintainer', either by sending a command to debian-bugs-request, or by
sending a copy of the message in which you forward the problem to
debian-bugs-forwarded@pixar.com.

2. You can send bug reports or extra information only to the
maintainer of the relevant package, by sending them to
debian-bugs-quiet@pixar.com.  This works on a per-message basis.

A few notes on procedure:

Don't mark a bug as done just because you've sent it on to whoever
maintains the upstream package.   Mark it as forwarded instead.  This
applies even if the upstream maintainer doesn't agree that it's a bug
(e.g., GNU programs lacking manpages).

Don't send all your bug reports to debian-bugs-quiet; instead, use it
only for trivial reports or large pieces of extra information the
maintainer has requested.  It is useful for developers to be aware of
the bugs reported against other packages, especially since bugs often
turn out to require at least a little thought by more than one
maintainer.

The full documentation on how to use the new features, and how to use
the system generally, can be found in the usual places - start at
 http://www.cl.cam.ac.uk/users/iwj10/debian-bugs/
or the mirror
 http://www.debian.org/Bugs/

I've attached a copy of the "developers' information" page, which will
also be on its way to ftp.debian.org in plain text form.

Thanks to Bruce for setting up the two new aliases at Pixar.

Ian.

         DEVELOPERS' INFORMATION REGARDING THE BUG PROCESSING SYSTEM

   Initially, a bug report is submitted by a user as an ordinary mail
   message to debian-bugs@pixar.com. This will then be given a number,
   acknowledged to the user, and forwarded to the debian-devel list.

   The Subject line will have Bug#nnn: added, and the Reply-To will be
   modified to include debian-bugs@pixar.com.

   A developer who sees a bug on debian-devel and takes responsibility
   for it should hit Reply in their favourite mailreader, and then edit
   the To field to include debian-bugs-done as well as or instead of the
   other addresses which are present (debian-bugs and the address of
   original submitter of the problem report).

   The developers' Subject line should look like Bug#nnn: or Re:
   Bug#nnn:, which will allow the script to mark that bug as processed.

   Whenever a message is received at debian-bugs-done with a Subject
   looking like either of those the corresponding bug will be marked as
   done, and brief messages confirming this will be sent to the original
   submitter of the bug report and to the person marking it as done.

   The message received at debian-bugs-done will not be forwarded
   anywhere. If it is desired that the submitter of the original report
   receive a copy so that they know why the bug is being marked as done
   (this will usually be the case) the person marking the bug as done
   should ensure that they include the submitter's address in the To or
   CC field.

   Anything that arrives at debian-bugs-done without Bug#nn or Re:
   Bug#nnn at the start of the Subject will be ignored, apart from
   generating a warning message that is hopefully clear enough to avoid
   confusing users who accidentally send messages to it.

   If a developer wishes to reply to a bug report without marking the bug
   as done they may simply reply to the message. Their reply will (by
   default) go to debian-bugs and to the original submitter of the bug
   report. The bug tracking system will file the reply reply with the
   rest of the logs for that bug report and forward it to debian-devel.
   The bug will not be marked as done.

   Every Friday a list of outstanding bug reports is posted to
   debian-devel; every Tuesday a list of bug reports that have gone
   unanswered too long is posted.

Some notes on procedure

   Don't mark a bug as done just because you've sent it on to whoever
   maintains the upstream package. Mark it as forwarded instead. This
   applies even if the upstream maintainer doesn't agree that it's a bug
   (e.g., GNU programs lacking manpages).

   Don't send all your bug reports to debian-bugs-quiet; instead, use it
   only for trivial reports or large pieces of extra information the
   maintainer has requested. It is useful for developers to be aware of
   the bugs reported against other packages, especially since bugs often
   turn out to require at least a little thought by more than one
   maintainer.

Recording that you have passed on a bug report

   When a developer forwards a bug report to the developer of the general
   source package from which the Debian package is derived, they should
   note this in the bug tracking system as follows:

   Make sure that the To field of your message to the author to has only
   the author(s) address(es) in it; put both the person who reported the
   bug and debian-bugs-forwarded@pixar.com in the CC field.

   Ask the author to preserve the CC to debian-bugs-forwarded and the
   Subject line when they reply, so that the bug tracking system will
   file their reply with the original report.

   When the bug tracking system gets a message at debian-bugs-forwarded
   it will mark the relevant bug as having been forwarded to the
   address(es) in the To field of the message it gets.

   Messages arriving at debian-bugs-forwarded without a valid bug report
   number will be handled much like similar messages to debian-bugs-done.


   You can also manipulate the `forwarded to' information by sending
   messages to debian-bugs-request.

Sending copies of bug reports to other addresses

   Sometimes it is necessary to send a copy of a bug report to some
   address other than debian-devel, which is where they are normally
   sent.

   You could do this by CC'ing your bug report to the other address(es),
   but then the other copies would not have the bug report number
   inserted in the Subject line. When the recipients reply they will
   probably preserve the debian-bugs entry in the header and have their
   message filed as a new bug report.

   The right way to do this is to use the X-Debian-CC header. Add a line
   like this to your message's mail header (not to the psuedo header with
   the Package field):

 X-Debian-CC: other-list@cosmic.edu

   This will cause the bug tracking system to send a copy of your report
   to the address(es) in the X-Debian-CC line as well as to debian-bugs.

   This feature can often be combined usefully with mailing
   debian-bugs-quiet - see below.

Direct-to-maintainer processing of bug reports

   The system usually sends problem reports and followup messages on to
   debian-devel. It is possible to get it not to forward these messages
   there, but to have them sent only to the relevant package maintainer.

   To do this, send the report or followup to debian-bugs-quiet@pixar.com
   instead of debian-bugs.

   This address will be preserved in the header so that people who do a
   `reply to all recipients' will send their messages to it too.

   You can use this feature when requesting information from the
   submitter of a bug report - if you CC your request to
   debian-bugs-quiet instead of debian-bugs and ask them in the body to
   do the same then they'll probably do so, so that only you see their
   message. (You may well see two copies - one that comes directly from
   them, and one that comes via the bug tracking system. Don't worry
   about this.)

    Unknown packages or bugs with no Package key

   If the bug tracking system doesn't know who the maintainer of the
   relevant package is it'll forward the report to debian-devel.

   When sending to debian-bugs-quiet you should make sure that the bug
   report is assigned to the right package, by putting a correct Package
   at the top of an original submission of a report, or by using the
   debian-bugs-request responder to (re)assign the report appropriately
   if it isn't correct already.

    Obsolete X-Debian-PR: quiet feature

   It used to be possible to prevent the bug tracking system from
   forwarding anywhere messages it received at debian-bugs, by putting an
   X-Debian-PR: quiet line in the actual mail header.

   This flag is still recognised for backwards compatibility, but now has
   the same effect as sending to debian-bugs-quiet.

Reopening, reassigning and manipulating bugs

   It is possible to reassign bug reports to other packages, to reopen
   erroneously-closed ones, and to modify the information saying to
   where, if anywhere, a bug report has been forwarded. This is done by
   sending mail to debian-bugs-request@pixar.com.

   The mail you send should be a series of commands, one per line. You'll
   receive a reply which looks like a transcript of your message being
   interpreted, with a response to each command. No notifications are
   sent to anyone; however, the messages are logged and made available in
   the WWW pages.

   The commands are:

   reassign bugnumber package
          Records that bug #bugnumber is a bug in package. This can be
          used to set the package if the user forgot the psuedo-header,
          or to change an earlier assignment.

   reopen bugnumber
          Reopens #bugnumber if it is closed. If it is not closed it
          won't do anything. If the bug is closed it is reopened, and you
          are recorded as the originator of the report, so that you will
          get the ack when it is closed again. This is to avoid flooding
          potentially-naive users with many notifications about the same
          report.

   forwarded bugnumber address
          Notes that #bugnumber has been forwarded to the upstream
          maintainer at address. This does not actually forward the
          report.

   notforwarded bugnumber
          Forgets any idea that bugnumber has been forwarded to any
          upstream maintainer.

   help
          Sends this help message.

   Suggestions for future features are welcome, though anything that
   requires the sending of notifications to various parties about the
   state(s) of bug report(s) is unlikely to be implemented.

Future plans

   At some point the Package: secondary header field may become mandatory
   - at the moment omitting it just produces a warning message.
     _________________________________________________________________

    Ian Jackson / iwj10@thor.cam.ac.uk. 14th January 1996.


Reply to: