Bugs/server-control.wml

[UCHIDA Norihiro <KY4N-UCD@xxxxxxxxxxxxxxx>]

Bugs/server-control.wml です。

---
内田憲宏 (UCHIDA Norihiro)
KY4N-UCD@xxxxxxxxxxxxxxx

#use wml::debian::template title="Debian BTS - コントロールサーバ" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.19"

<h1>バグコントロールメールサーバ入門</h1>

<P><code>request@bugs.debian.org</code>宛ての電子メールによって
バグ報告記録や関連文書を取り寄せることができるメールサーバがあります。
また、<code>control@bugs.debian.org</code>によってバグ報告を
いろいろな方法で操作できるメールサーバもあります。</P>

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

<P>どちらかのアドレスにメールを送る場合のメールサーバの基本操作と
利用可能な共通コマンドの詳細については WWW上の
<A href="server-request#introduction">リクエストサーバ入門</A>、
ファイル <code>bug-log-mailserver.txt</code>、または
どちらかのメールサーバに <code>help</code> を送ることで参照できます。</P>

<P>メールサーバの <A href="server-refcard">リファレンスカード</A>
を WWW 上やファイル <code>bug-mailserver-refcard.txt</code> で参照
できます。または、電子メールで <code>refcard</code> コマンドを送る
ことでも利用できます。</P>

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

<dl>

<dt><code>reassign</code> <var>bugnumber</var> <var>package</var>
<dd>

バグ報告 #<var>bugnumber</var> が <var>package</var> のバグであること
を記録します。このコマンドは、ユーザが擬似ヘッダをつけ忘れた場合に
パッケージを設定したり、以前のパッケージ設定を変更するために利用されます。
この変更による通知は(処理中の写しの通常情報以外は)誰にも送られません。

<dt><code>reopen</code> <var>bugnumber</var>
 [ <var>originator-address</var> | <code>=</code> | <code>!</code> ]
<dd>

バグ報告 #<var>bugnumber</var> がクローズされている場合、再オープンします。

<p>デフォルトで、または <code>=</code> を指定することで、元々の報告者が
そのまま再オープンされたバグ報告の報告者となります。そのため、元々の報告者は
そのバグ報告が再びクローズされる時に通知を受け取ることになります。</p>

<p><var>originator-address</var> を指定した場合は、バグ報告者のアドレス
を設定できます。自分が再オープンしたバグ報告の新しい報告者
になる場合は、<code>!</code> を使用するか、または自分の電子メールアドレス
を指定します。</p>

<p>通常は、バグ報告の元々の報告者に再オープンしようとしていることを
連絡すると良いでしょう。それによって、再びバグがクローズされた時に
通知を受け取ることを予想できます。</p>

<p>バグがクローズされていない場合、reopen は何もせず、報告者の変更も行いません。
未解決バグ報告の報告者を変更する方法はありません
(これは意図的であり、報告したバグについて誰からも何の発言も無いうちに
バグがクローズされ28日後にバグが消去されてしまうことを防ぎます)。

<dt><code>forwarded</code> <var>bugnumber</var> <var>address</var>
<dd>

バグ報告 <var>bugnumber</var> がパッケージの原作者のアドレス
<var>address</var> に転送されていることを記録します。バグ報告自体は
実際には転送されません。このコマンドは、間違った forwarded-to アドレス
を変更したり、転送済であることが記録されていないバグに対して
新しいアドレスを指定したりするのに使用できます。

<dt><code>notforwarded</code> <var>bugnumber</var>
<dd>

<var>bugnumber</var> が任意のパッケージ原作者に転送済である
という記録を抹消します。バグ報告が転送済でない場合、
このコマンドは何もしません。

<dt><code>retitle</code> <var>bugnumber</var> <var>new-title</var>
<dd>

指定したバグ報告のタイトルを変更します
(デフォルトは元々のバグ報告の <code>Subject</code> メールヘッダが
使われます)。

<p>他の多くのバグ操作コマンドと異なり、このコマンドをマージされたバグ報告
のひとつに用いた場合、変更を要求したバグ報告のタイトルのみが変更され、
マージされている全てのバグ報告のタイトルは変更されません。

<dt><code>severity</code> <var>bugnumber</var> <var>severity</var>
<dd>

<p>バグ報告 #<var>bugnumber</var> の重要度 (severity レベル) を
<var>severity</var> に設定します。この変更はバグを報告したユーザには
通知されません。</p>

<p>severity には 
<code>critical(致命的)</code>、<code>grave(重大)</code>、
<code>serious(深刻)</code>、<code>important(重要)</code>、
<code>normal(通常)</code>、<code>minor(軽度)</code>、
<code>wishlist(要望)</code> があります。

<p><A href="Developer#severities">これらの意味</A>については、
バグシステムの一般開発者文書で調べてください。

<dt><code>merge</code> <var>bugnumber</var> <var>bugnumber</var> ...
<dd>

2つ、またはそれ以上のバグ報告をマージします。
バグ報告がマージされると、マージされたバグ報告の任意の一つに対して
オープン、クローズ、転送済としてマーク・マーク解除したり、新しい
パッケージに再指定したりした場合に、マージされたバグ報告全てに同
じ操作が行なわれます。

<p>バグ報告をマージするためには、それらが厳密に同じ状態でなければなりません。
つまり、すべてのバグがオープンであるかクローズであり、すべて同じ原作者
のアドレスに転送済となっているか未転送になっていて、すべてのバグが
同じパッケージ (群) を対象としていて
(バグが対象としているパッケージについて完全な文字列比較が行われます)、
すべてのバグが同じ重要度 (severity) になっていないといけません。
それらのバグが同じ状態でない場合、<code>merge</code> コマンドを使用
する前に、<code>reassign</code>、<code>reopen</code> 等を使って
同じ状態にしなければなりません。</p>

<P><code>merge</code> コマンドで与えられた任意のバグが既に別のバグに
マージされている場合、コマンドに与えられた任意のバグにマージされ
ているすべてのバグがマージされます。「マージ」は(数学の)等号に似て
おり、再帰性、推移性、対称性を持ちます。</p>

<P>バグ報告をマージすると、それぞれの報告のログに註釈を記録します。
WWWページ上では、マージされている他のバグへのリンクが含められます。</p>

<P>マージされたバグ報告は、バグ報告それぞれの抹消期限が満了した後で、
すべて同時に抹消されます。

<dt><code>unmerge</code> <var>bugnumber</var>
<dd>

指定したバグ報告を、これにマージされていた他のバグ報告から分離します。
指定したバグ報告が複数のバグ報告にマージされていた場合は、指定したバグ
報告以外はすべてマージされたままとなります。
明示的に指定したバグのみが結合を取り除かれます。

<p>ひとつにマージされた多くのバグ報告を 2 つのグループに分けたい場合は、
新しいグループに移したいバグ報告をそれぞれ個別にアンマージし、それから
新しいグループにマージしなければなりません。</p>

<p><code>unmerge</code> コマンド一回でバグ報告をひとつだけアンマージする
ことができます。複数のバグ報告を分離したい場合は、メール本文に複数の
<code>unmerge</code> コマンドを含めてください。

<dt><code>tags</code> <var>bugnumber</var> [ <code>+</code> | <code>-</code> | <code>=</code> ] <var>tag</var>

  <dd>バグ報告 #<var>bugnumber</var> に特定のタグ <var>tag</var> を設定します。
  バグの報告者には通知は届きません。
  <code>+</code> は追加を、<code>-</code>は削除を、<code>=</code>は
  現在のタグを無視して新しいタグを付けなおすことを意味します。
  デフォルトの動作は追加です。+/-/= の文字とタグ名の間には
  スペースが必要です。

  <p>現在、有効なタグには <code>patch(パッチ)</code>、
  <code>wontfix(修正予定無)</code>、<code>moreinfo(追加情報)</code>、
  <code>unreproducible(再現不可能)</code>、 <code>help(助力)</code>、
  <code>pending(保留)</code>、 <code>fixed(修正済)</code>、
  <code>security(セキュリティ)</code>、 <code>upstream(上流)</code>、
  <code>potato</code>、 <code>woody</code>、 <code>sid</code> があります。

  <p><a href="Developer#tags">これらの意味</a> については、
  バグシステムに関する開発者情報で調べてください。

<dt><code>close</code> <var>bugnumber</var>
<dd>

バグ報告 #<var>bugnumber</var> をクローズします。

<P>バグを報告したユーザに通知が送られます。しかし、
(<var>bugnumber</var><code>-done@bugs</code> にメールを送った場合と
違って)バグをクローズしたメールの本文はその通知に<em>添付されません</em>。
バグ報告をクローズしたメンテナは、別にメッセージを送るなどして、
バグを報告したユーザがなぜそのバグがクローズされたか確実に分かる
ようにしなければなりません。

</dl>

<hr>

#use "otherpages.inc"

#use "footer.inc"