server-control.html

[NABETANI Hidenobu <nabetani@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

鍋谷です。

大変遅くなりましたが、server-control.html ができました。
自分で見てもかなり怪しい訳がありますので、おいおい直していこうと思って
います。ひとつ分からないのは、

>       If any of the bugs listed in a merge command is already merged
>       with another bug then all the reports merged with any of the ones
>       listed will all be merged together. Merger is like equality: it is
>       reflexive, transitive and symmetric. 

の最後の文章です。

大阪大学理学研究科物理学専攻 博士後期課程1年 大坪研究室(06-850-5346)
         鍋谷 栄展      nabetani@xxxxxxxxxxxxxxxxxxxxxxxxxxx

----------------------------------------------------------------------------
> Introduction to the bug control and manipulation mailserver

バグコントロールメールサーバ入門

> In addition to the mailserver on request@bugs.debian.org which allows
> the retrieval of bug data and documentation by email, there is another
> server on control@bugs.debian.org which also allows bug reports to be
> manipulated in various ways. 

電子メールによってバグ報告のデータと文書を訂正できるメールサーバ 
(request@bugs.debian.org)に加えて、バグ報告をいろいろな方法で操作でき
るサーバ (control@bugs.debian.org) があります。 

> The control server works just like the request server, except that it has
> some additional commands; in fact, it's the same program. The two
> addresses are only separated to avoid users making mistakes and causing
> problems while merely trying to request information. 

コントロールサーバは、いくつかの追加コマンドがある以外はリクエスト
サーバと同じ動作をします。実際に、これらのサーバは同じプログラムな
のです。アドレスを2つに分けた理由は、ユーザが単に情報を要求してい
るだけ である場合に、誤って問題が起きるのを避けるためです。 

> Please see the introduction to the request server available on the World
> Wide Web, in the file bug-maint-mailcontrol.txt, or by sending help to
> either mailserver, for details of the basics of operating the mailservers
> and the common commands available when mailing either address. 

どちらかのアドレスにメールを送る場合の メールサーバの基本操作と利用
可能な共通コマンドの詳細については WWW 上の リクエストサーバ入門
、ファイル bug-maint-mailcontrol.txt、 又はどちらかのメール
サーバに help を送ることで参照して ください。 

> The reference card for the mailservers is available via the WWW, in 
> bug-mailserver-refcard.txt or by email using the refcard command). 

メールサーバのリファレンスカードを WWW 上、
ファイル bug-mailserver-refcard.txt で、又は 電子メールで
refcard コマンドを送ることで利用できます。 

> Commands available only at the control mailserver

コントロールメールサーバのみで利用可能なコマンド

> close bugnumber
>       Close bug report #bugnumber. 
> 
>       A notification is sent to the user who reported the bug, but (in
>       contrast to mailing bugnumber-done@bugs) the text of the mail
>       which caused the bug to be closed is not included in that
>       notification. The maintainer who closes a report should ensure,
>       probably by sending a separate message, that the user who
>       reported the bug knows why it is being closed. 
close bugnumber 
     バグ報告 #bugnumber をクローズします。 

     バグを報告したユーザに通知が行きます。 しかし、
     (bugnumber-done@bugs にメールを送る場合と 異なり、)バグをク
     ローズしたメールの文書はその通知に含められません。 報告をクロ
     ーズしたメンテナーは、 別にメッセージを送るなどして バグ報告を
     したユーザがなぜそのバグがクローズされたか分かるような 保証を
     すべきです。 

> 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 pseudo-header, or to
>       change an earlier assignment. No notifications are sent to anyone
>       (other than the usual information in the processing transcript). 
reassign bugnumber package 
     バグ報告 #bugnumber が package のバグであることを 記録します。こ
     のコマンドは、ユーザが疑似ヘッダをつけ忘れた場合に パッケージ
     を設定するためや、以前の指定を変更するために利用されます。 こ
     の通知は(登録中の写しの通常情報以外に)誰にも送られません。 

> reopen bugnumber [ originator-address | = | ! ] 
>       Reopens #bugnumber if it is closed. 
> 
>       By default, or if you specify =, the original submitter is still as
>       the originator of the report, so that they will get the ack when it
>       is closed again. 
reopen bugnumber [ originator-address | = | ! ] 
     バグ報告 #bugnumber がクローズされているなら、リオープンしま
     す。 

     デフォルトで、又は = を指定することで、 元々の報告者がそのまま
     その報告の発起人となります。 そのため、その報告が再びクローズ
     された時に通知を受け取ることに成ります。 

>       If you supply an originator-address the originator will be set to
>       the address you supply. If you wish to become the new originator 
>       of the reopened report you can use the ! shorthand or specify your
>       own email address. 
> 
>       It is usually a good idea to tell the person who is about to be
>       recorded as the originator that you're reopening the report, so that
>       they will know to expect the ack which they'll get when it is closed
>       again. 
     originator-address を与えることで、 発起人のアドレスを設定できま
     す。 あなたがそのリオープンしたバグ報告の新しい発起人となりた
     いのでしたら、 ! を使うか、もしくは自分自身の電子メールアドレ
     スを指定する ことができます。 

     通常、記録しようとする人がバグ報告をリオープンする発起人とな
     る のは良い考えです。そうすると、再びクローズされたときに 通知
     を受け取ることを期待できます。 

>       If the bug is not closed then reopen won't do anything, not even
>       change the originator. There is no way to change the originator of
>       an open bug report (this is deliberate, so that you can't have a bug
>       be closed and then deleted 28 days later without someone being
>       told about it). 
     バグがクローズされていないなら、reopen は何もしません。発起人
     の変更も 行いません。未解決バグ報告の発起人を変更する方法はあ
     りません (これは意図的であり、それでそのバグについて誰かが何
     も言わないうちに バグをクローズし28日後に消去することはできま
     せん)。 

> forwarded bugnumber address
>       Notes that bugnumber has been forwarded to the upstream
>       maintainer at address. This does not actually forward the report.
>       This can be used to change an existing incorrect forwarded-to
>       address, or to record a new one for a bug that wasn't previously
>       noted as having been forwarded. 
forwarded bugnumber address 
     bugnumberがアドレス address を持つ 次のメンテナーにフォワードさ
     れていることを記録します。 このコマンドは、実際にそのバグ報告
     をフォワードしません。 このコマンドは、間違った forwarded-to ア
     ドレスを変更するためや、 以前にフォワードされていなかったバグ
     に対して新しいアドレスを記録する ために使用できます。 

> notforwarded bugnumber
>       Forgets any idea that bugnumber has been forwarded to any
>       upstream maintainer. If the bug was not recorded as having been
>       forwarded then this will do nothing. 
notforwarded bugnumber 
     bugnumber が任意の次のメンテナーにフォワードされている という
     認識を忘れさせます。バグがフォワードされているとして記録され
     て いないなら、このコマンドは何もしません。 

> retitle bugnumber new-title
>       Changes the title of a bug report to that specified (the default is
>       the Subject mail header from the original report. 
> 
>       Unlike most of the other bug-manipulation commands when used
>       on one of a set of merged reports this will change the title of only
>       the individual bug requested, and not all those with which it is
>       merged. 
retitle bugnumber new-title 
     指定されたバグ報告のタイトルを変更します。 (デフォルトはオリ
     ジナルバグ報告のメールヘッダの Subjectです。) 

     他の多くのバグ操作コマンドと異なり、 マージされたバグ報告のひ
     とつに用いたときに 要求のった個々のバグ報告のみタイトルを変更
     し、 マージされたバグ報告全てのタイトルを変更しません。 

> severity bugnumber severity
>       Set the severity level for bug report #bugnumber to severity. No
>       notification is sent to the user who reported the bug. 
> 
>       Severities are critical, grave, normal and wishlist. For their
>       meanings please consult the general developers' documentation for
>       the bug system. 
severity bugnumber severity 
     バグ報告 #bugnumber に対する severity レベルを severity に設定しま
     す。 そのバグを報告したユーザには通知されません。 

     severitiy には、critical(致命的), grave(重大), normal(通
     常),wishlist(要望)があります。 これらの意味 についてはバグ
     システムの一般開発者文書を調べてください。 

> merge bugnumber bugnumber ... 
>       Merges two or more bug reports. When reports are merged
>       opening, closing, marking or unmarking as forwarded and
>       reassigning any of the bugs to a new package will have an identical
>       effect on all of the merged reports. 
merge bugnumber bugnumber ... 
     2つ、又はそれ以上のバグ報告をマージします。 バグ報告がマージ
     されると、 オープン、クローズ、転送済としてマーク・アンマー
     ク、 そのバグのいずれかを新しいパッケージに再指定することは マ
     ージされたバグ報告全てに同一の効果を持ちます。 

>       Before bugs can be merged they must be in exactly the same state:
>       either all open or all closed, with the same forwarded-to upstream
>       author address or all not marked as forwarded, and all assigned to
>       the same package or package(s) (an exact string comparison is
>       done on the package to which the bug is assigned). If they don't
>       start out in the same state you should use reassign, reopen and so
>       forth to make sure that they are before using merge. 
     バグがマージされる前に、それらが厳密に同じ主張である必要があ
     ります。 すべてオープンであるかすべてクローズであり、 同じ
     forwarded-to upstream author アドレスを持つかすべて転送済として
     マークされていて、すべて同じパッケージ又はパッケージ群に指定
     されている (バグが指定されているパッケージについて exact string
     comparison が行わ れます)ことが必要です。それらのバグが同じ主
     張をしていないなら、 merge する前にreassign、reopen等 を
     用いてそれらが同じであることを確認すべきです。 

>       If any of the bugs listed in a merge command is already merged
>       with another bug then all the reports merged with any of the ones
>       listed will all be merged together. Merger is like equality: it is
>       reflexive, transitive and symmetric. 
> 
>       Merging reports causes a note to appear on each report's logs; on
>       the WWW pages this is includes links to the other bugs. 
> 
>       Merged reports are all expired simultaneously, and only when all of
>       the reports each separately meet the criteria for expiry. 
     mergeコマンドにあげられた任意のバグが既に別のバグとマージ さ
     れているならば、コマンドにあげられた任意のバグとマージされた
     すべての バグがマージされます。 Merger is like equality: it is reflexive,
     transitive and symmetric. 

     マージされたバグ報告は、それぞれの報告のログに注意書きがされ
     ます。 WWW ページ上では、他のバグへのリンクが含められます。 

     マージされたバグ報告は同時に全て消去されます。 消去されるの
     は、全てバグ報告がそれぞれの満期を満たした場合だけです。 

> unmerge bugnumber
>       Disconnects a bug report from any other reports with which it may
>       have been merged. If the report listed is merged with several
>       others then they are all left merged with each other; only their
>       associations with the bug explicitly named are removed. 
unmerge bugnumber 
     バグ報告 #bugnumber をこれとマージされていた別のバグ報告から
     ディスコネクトします。 リストにあげられたバグ報告がいくつかの
     別の報告とマージされているなら、 それらは全てマージされたまま
     です。 明示的にあげたバグとの結合のみが取り除かれます。 

>       If many bug reports are merged and you wish to split them into two
>       separate groups of merged reports you must unmerge each report
>       in one of the new groups separately and then merge them into the
>       required new group. 
     多くのバグ報告がマージされていて、それを2つのグループに分け
     たいの でしたら、新しいあるグループにある報告をそれぞれ個別に
     アンマージし、 それからそれらのバグ報告を必要な新しいグループ
     にマージしなければな りません。 

> You can only unmerge one report with each unmerge command; if
> you want to disconnect more than one bug simply include several 
> unmerge commands in your message. 
     それぞれの unmerge コマンドでバグ報告をひとつだけ unmaerge す
     ることができます。一つ以上のバグ報告をディスコネクトしたいの
     でしたら、 単にメッセージに複数の unmerge コマンドを含めてく
     ださい。 
---------------------------------------------------------------------------