home *** CD-ROM | disk | FTP | other *** search
/ Dream 46 / Amiga_Dream_46.iso / bo / extras / doc / bug-maint-mailcontrol.txt < prev    next >
Text File  |  1996-10-22  |  7KB  |  130 lines
  1.  
  2.           Introduction to the bug control and manipulation mailserver
  3.                                        
  4.    In addition to the mailserver on request@bugs.debian.org which allows
  5.    the retrieval of bug data and documentation by email, there is another
  6.    server on control@bugs.debian.org which also allows bug reports to be
  7.    manipulated in various ways.
  8.    
  9.    The control server works just like the request server, except that it
  10.    has some additional commands; in fact, it's the same program. The two
  11.    addresses are only separated to avoid users making mistakes and
  12.    causing problems while merely trying to request information.
  13.    
  14.    Please see the introduction to the request server available on the
  15.    World Wide Web, in the file bug-maint-mailcontrol.txt, or by sending
  16.    help to either mailserver, for details of the basics of operating the
  17.    mailservers and the common commands available when mailing either
  18.    address.
  19.    
  20.    The reference card for the mailservers is available via the WWW, in
  21.    bug-mailserver-refcard.txt or by email using the refcard command).
  22.    
  23.                Commands available only at the control mailserver
  24.                                        
  25.    close bugnumber
  26.           Close bug report #bugnumber.
  27.           
  28.           A notification is sent to the user who reported the bug, but
  29.           (in contrast to mailing bugnumber-done@bugs) the text of the
  30.           mail which caused the bug to be closed is _not_ included in
  31.           that notification. The maintainer who closes a report should
  32.           ensure, probably by sending a separate message, that the user
  33.           who reported the bug knows why it is being closed.
  34.           
  35.    reassign bugnumber package
  36.           Records that bug #bugnumber is a bug in package. This can be
  37.           used to set the package if the user forgot the pseudo-header,
  38.           or to change an earlier assignment. No notifications are sent
  39.           to anyone (other than the usual information in the processing
  40.           transcript).
  41.           
  42.    reopen bugnumber [originator-address|=]
  43.           Reopens #bugnumber if it is closed.
  44.           
  45.           By default you are recorded as the originator of the report, so
  46.           that you will get the ack when it is closed again. This is to
  47.           avoid flooding potentially-naive users with many notifications
  48.           about the same report.
  49.           
  50.           If you supply an originator-address the originator will be set
  51.           to the address you supply; you can use = to keep the originator
  52.           the same as it was before. It is usually a good idea to tell
  53.           the person who is about to be recorded as the originator that
  54.           you're reopening the report, so that they will know to expect
  55.           the ack which they'll get when it is closed again.
  56.           
  57.           If the bug is not closed then reopen won't do anything, not
  58.           even change the originator. There is no way to change the
  59.           originator of an open bug report (this is deliberate, so that
  60.           you can't have a bug be closed and then deleted 28 days later
  61.           without someone being told about it).
  62.           
  63.    forwarded bugnumber address
  64.           Notes that bugnumber has been forwarded to the upstream
  65.           maintainer at address. This does not actually forward the
  66.           report. This can be used to change an existing incorrect
  67.           forwarded-to address, or to record a new one for a bug that
  68.           wasn't previously noted as having been forwarded.
  69.           
  70.    notforwarded bugnumber
  71.           Forgets any idea that bugnumber has been forwarded to any
  72.           upstream maintainer. If the bug was not recorded as having been
  73.           forwarded then this will do nothing.
  74.           
  75.    retitle bugnumber new-title
  76.           Changes the title of a bug report to that specified (the
  77.           default is the Subject mail header from the original report.
  78.           
  79.           Unlike most of the other bug-manipulation commands when used on
  80.           one of a set of merged reports this will change the title of
  81.           only the individual bug requested, and not all those with which
  82.           it is merged.
  83.           
  84.    merge bugnumber bugnumber ...
  85.           Merges two or more bug reports. When reports are merged
  86.           opening, closing, marking or unmarking as forwarded and
  87.           reassigning any of the bugs to a new package will have an
  88.           identical effect on all of the merged reports.
  89.           
  90.           Before bugs can be merged they must be in exactly the same
  91.           state: either all open or all closed, with the same
  92.           forwarded-to upstream author address or all not marked as
  93.           forwarded, and all assigned to the same package or package(s)
  94.           (an exact string comparison is done on the package to which the
  95.           bug is assigned). If they don't start out in the same state you
  96.           should use reassign, reopen and so forth to make sure that they
  97.           are before using merge.
  98.           
  99.           If any of the bugs listed in a merge command is already merged
  100.           with another bug then all the reports merged with any of the
  101.           ones listed will all be merged together. Merger is like
  102.           equality: it is reflexive, transitive and symmetric.
  103.           
  104.           Merging reports causes a note to appear on each report's logs;
  105.           on the WWW pages this is includes links to the other bugs.
  106.           
  107.           Merged reports are all expired simultaneously, and only when
  108.           all of the reports each separately meet the criteria for
  109.           expiry.
  110.           
  111.    unmerge bugnumber
  112.           Disconnects a bug report from any other reports with which it
  113.           may have been merged. If the report listed is merged with
  114.           several others then they are all left merged with each other;
  115.           only their associations with the bug explicitly named are
  116.           removed.
  117.           
  118.           If many bug reports are merged and you wish to split them into
  119.           two separate groups of merged reports you must unmerge each
  120.           report in one of the new groups separately and then merge them
  121.           into the required new group.
  122.           
  123.           You can only unmerge one report with each unmerge command; if
  124.           you want to disconnect more than one bug simply include several
  125.           unmerge commands in your message.
  126.           
  127.      _________________________________________________________________
  128.                                       
  129.     Ian Jackson / owner@bugs.debian.org. 20th July 1996.
  130.