[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bugs/server-control (1.57)
http://www.debian.org/Bugs/server-control
1.57
--
victory
don't include my addresses in mail body...
---------------------------------------------------------
#use wml::debian::template title="Debian BTS — 制御サーバ" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.57"
<h1>バグ制御とメールサーバの操作</h1>
<p>バグデータや説明を取得できるメールサーバ
<code>request@bugs.debian.org</code> に加えて、バグ報告を別のサーバ
<code>control@bugs.debian.org</code>
から様々な方法で操作することができます。</p>
<p>制御サーバはコマンドが追加されていますが、
リクエストサーバと同じように動作します; 実のところ同一のプログラムです。
単に情報を取得する際にミスで問題を起こすのを避けるためだけの目的でこの
2 つのアドレスに分けられています。</p>
<p>制御サーバへの特定のコマンドは実際にバグの状態を変更するので、
変更されたバグが割り当てられているパッケージのメンテナには、
コマンドの処理に関する通知が送られます。
さらに、サーバへ送られたメールと変更の結果はバグ報告にログとして残ります。
これらは WWW ページで参照可能です。</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>バグ番号</var> <var>パッケージ</var>
[ <var>バージョン</var> ]</dt>
<dd>
バグ報告 #<var>バグ番号</var>が<var>パッケージ</var>のバグであること
を記録します。このコマンドは、ユーザが擬似ヘッダをつけ忘れた場合に
パッケージを設定したり、以前のパッケージ設定を変更するために利用されます。
この変更による通知は(処理中の写しの通常情報以外は)誰にも送られません。
<p><var>バージョン</var>が指示された場合は、バグ追跡システムはそのバグが
新しく割り当てられたパッケージのそのバージョンに影響することを記録します。</p></dd>
<dt><code>reopen</code> <var>バグ番号</var>
[ <var>報告者アドレス</var> | <code>=</code> | <code>!</code> ]</dt>
<dd>
バグ報告 #<var>バグ番号</var>が閉じられている場合、再開します。
<p>デフォルトあるいは <code>=</code>
を指定した場合、元の報告者がそのままこの報告の報告者となり、
再び閉じられる時に通知を受け取ることになります。</p>
<p><var>報告者アドレス</var>を指定した場合、
そのアドレスが報告者としてセットされます。
自分を再開したバグの新しい報告者にする場合は、短縮形の <code>!</code>
を使用するか、自分のメールアドレスを指定してください。</p>
<p>通常は元々の報告者に
自分がそのバグ報告を再開しようとしていることを連絡すると良いでしょう。
それによって、再びバグが閉じられた時に通知を受け取ることが期待できます。</p>
<p>バグが閉じられていない場合、reopen
は何もせず、報告者の変更も行いません。未解決バグの報告者を変更するには、
<code>submitter</code> コマンドを使います。
このコマンドを使うと元々の報告者に通知されることに注意してください。
<p>バグがそのパッケージの特定のバージョンで一旦閉じられてから、
以降のバージョンで再発した場合は、かわりに
<code>found</code> コマンドを使用してください。</p></dd>
<dt><code>found</code> <var>バグ番号</var> [ <var>バージョン</var> ]</dt>
<dd>#<var>バグ番号</var>が割り当てられているパッケージの指定された
<var>バージョン</var>で発生したことを記録します。
<p>バグ追跡システムはこの情報とバグを閉じるときに記録するバージョンを合わせて利用して、
それぞれのパッケージの複数のバージョンに対するバグの状況を示します。
修正されたバージョンが存在しない、
あるいは修正の後に再現されたものは未解決と見なします。</p>
<p><var>バージョン</var>が指定されない場合は、
そのバグの修正されたバージョンのリストがクリアされます。これは
<code>reopen</code> と同じ事になります。</p>
<p><code>reopen</code>
の書式で<var>バージョン</var>を追加するのが苦痛となっていることから、
このコマンドが導入されました。</p></dd>
<dt><code>notfound</code> <var>バグ番号</var> <var>バージョン</var></dt>
<dd>#<var>バグ番号</var>が割り当てられているパッケージの指定された
<var>バージョン</var>で見つかったという記録を削除します。
<p>これはそのバージョンで修正済みとしてバグを閉じるのとは異なり、
そのバグがどちらのバージョンでも修正済みにはなりません;
そのバージョンに対する情報はなくなります。
これはバグが見つかった記録の誤りの修正に向いています。</p></dd>
<dt><code>submitter</code> <var>バグ番号</var>
<var>報告者アドレス</var> | <code>!</code></dt>
<dd>
バグ報告 #<var>バグ番号</var>の報告者を<var>報告者アドレス</var>
に変更します。
<p>自分を新しい報告者にしたい場合は、短縮形の <code>!</code>
を使うか、自分のメールアドレスを指定してください。</p>
<p><code>reopen</code>
コマンドが再開の対象となるバグに結合されたバグの報告者も変更するのに対して、
<code>submitter</code> では結合されたバグを変更しません。</p></dd>
<dt><code>forwarded</code> <var>バグ番号</var> <var>アドレス</var></dt>
<dd>
<var>バグ番号</var>が<var>アドレス</var>で示す、
上流の保守担当者に転送されることに注意してください。
これは実際の転送は行いません。これは誤った forwarded-to
アドレスの変更や、これまでに転送されてきたものではない、
新しいアドレスを記録するのに使います。</dd>
<dt><code>notforwarded</code> <var>バグ番号</var></dt>
<dd>
<var>バグ番号</var>を転送していた上流の保守担当者の情報を抹消します。
バグ報告の転送記録がない場合は何も行いません。</dd>
<dt><code>retitle</code> <var>バグ番号</var> <var>新しい題名</var></dt>
<dd>
指定したバグ報告の題名を変更します(元々のバグ報告のメールヘッダの
<code>Subject</code> がデフォルトとなります)。
<p>他のほとんどのバグ操作コマンドと異なり、
結合されたバグ報告のひとつに用いた場合、
変更を要求したバグ報告の題名のみが変更され、
結合されているバグ報告すべての題名が変更されるわけではありません。</p></dd>
<dt><code>severity</code> <var>バグ番号</var> <var>severity</var></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var> の重要度レベルを <var>severity</var>
に設定します。バグを報告したユーザには通知されません。</p>
<p>重要度には <code>critical(致命的)</code>、<code>grave(重大)</code>、
<code>serious(深刻)</code>、<code>important(重要)</code>、
<code>normal(通常)</code>、<code>minor(軽度)</code>、
<code>wishlist(要望)</code> があります。</p>
<p><a href="Developer#severities">これらの意味</a>については、
バグシステムの一般開発者文書で調べてください。</p></dd>
<dt><code>clone</code> <var>バグ番号</var> <var>新 ID</var> [ <var>新 ID</var> ... ]</dt>
<dd>clone 制御コマンドによりバグ報告を複製することができます。
これは、一つの報告が実際には複数のバグを指摘しているような場合に便利です。
"<var>新 ID</var>" はスペース区切りのマイナスの数値で、
以降のコマンドから新しく複製されたバグを参照するのに使うことができます。
新しいバグ報告は、それぞれの new ID に対して作成されます。
<p>使用例:</p>
<pre>
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo sucks
reassign -2 bar
retitle -2 bar: bar sucks when used with foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo sucks
merge -1 -3
</pre></dd>
<dt><code>merge</code> <var>バグ番号</var> <var>バグ番号</var> ...</dt>
<dd>
複数のバグ報告を結合します。バグ報告が結合されると、
結合されたバグ報告の任意の一つに対してオープン、クローズ、
転送済としてマーク、マーク解除、新しいパッケージの再指定の場合に、
結合されたバグ報告すべてに対して同じ操作が行なわれます。
<p>バグ報告を結合する場合には、それらが厳密に同じ状態でなければなりません:
バグがすべてオープンであるかクローズで、
すべて同じ上流担当者のアドレスに転送、あるいは未転送になっていて、
バグがすべて同じパッケージ (群) を対象としていて
(バグが対象としているパッケージについて完全な文字列比較が行われます)、
バグがすべて同じ重要度 (severity) になっていないといけません。
対象のバグが同じ状態でない場合、<code>merge</code>
コマンドを使用する前に、<code>reassign</code>、<code>reopen</code>
等を使って同じ状態にしなければなりません。
タイトルが一致している必要はなく、結合により影響を受けることもありません。
同様にタグも影響を受けません。それらは結合されます。</p>
<p><code>merge</code>
コマンドで与えられた任意のバグが既に別のバグに結合されている場合、
コマンドに与えられた任意のバグに結合されているバグがすべて結合されます。
「結合」は(数学の)等号に似て、再帰性、推移性、対称性があります。</p>
<p>バグ報告を結合すると、それぞれの報告のログに注釈を記録します。
WWW ページ上では、結合されている他のバグへのリンクが含められます。</p>
<p>結合されたバグ報告は、バグ報告それぞれの抹消期限がすべて満了した後で、
すべて同時に抹消されます。</p></dd>
<dt><code>forcemerge</code> <var>バグ番号</var> <var>バグ番号</var> ...</dt>
<dd>複数のバグ報告を強制的に結合します。
リストの先頭のバグがマスターとなり、その設定
(設定は通常の結合と同様に一致していなければなりません)
が以降のバグに割り当てられます。誤記による誤った結合を防ぐため、
バグはすべて同じパッケージのものでなければなりません。
結合が意味することについては上記の説明文を参照してください。
<p>これを使うと結合でバグを閉じることができるということに注意してください;
これを行う場合は、
閉じるにあたって適切なメッセージを報告者に通知する責任があります。</p>
</dd>
<dt><code>unmerge</code> <var>バグ番号</var></dt>
<dd>
指定したバグ報告を、これに結合されていた他のバグ報告から分離します。
指定したバグ報告が複数のバグ報告に結合されていた場合は、
指定したバグ報告以外はすべて結合されたままとなります;
明示的に指定したバグのみが結合を解除されます。
<p>多くのバグ報告が一つに結合されているのを二つのグループに分けたい場合は、
新しいグループに移したいバグ報告をそれぞれ個別に分離し、
それから新しいグループに結合しなければなりません。</p>
<p><code>unmerge</code>
コマンド一つで分離することができるバグ報告は一つだけです。
複数のバグ報告を分離したい場合は、メール本文に複数の
<code>unmerge</code> コマンドを含めてください。</p></dd>
<dt><code>tags</code> <var>バグ番号</var> [ <code>+</code> | <code>-</code>
| <code>=</code> ] <var>タグ</var> [ <var>タグ</var> ... ]</dt>
<dd>バグ報告 #<var>バグ番号</var> にタグを設定します。
バグの報告者には通知されません。<code>+</code> は追加、<code>-</code>
は削除、<code>=</code>は
現在のタグを無視して新しいタグを付けなおすことをそれぞれ意味します。
デフォルトの動作は追加です。
<p>使用例:</p>
<pre>
\# 'tags 123456 + patch' と同じ
tags 123456 patch
\# 'tags 123456 + help security' と同じ
tags 123456 help security
\# 'fixed' と 'pending' タグを追加
tags 123456 + fixed pending
\# 'unreproducible' タグを削除
tags 123456 - unreproducible
\# 'moreinfo' タグと 'unreproducible' タグだけを設定
tags 123456 = moreinfo unreproducible
</pre>
<p>現在、有効なタグには <code>patch(パッチ)</code>、
<code>wontfix(修正予定無)</code>、<code>moreinfo(追加情報)</code>、
<code>unreproducible(再現不可能)</code>、 <code>help(助力)</code>、
<code>pending(保留)</code>、 <code>fixed(修正済)</code>、
<code>fixed-in-experimental(experimentalで修正済)</code>,
<code>fixed-upstream(上流で修正済)</code>,
<code>security(セキュリティ)</code>、 <code>upstream(上流)</code>、
<code>confirmed(確認済)</code>、 <code>d-i(インストーラ)</code>、
<code>ipv6</code>、<code>lfs</code>、<code>l10n</code>、
<code>potato</code>、<code>woody</code>、<code>sarge</code>、
<code>sarge-ignore</code>、<code>etch</code>、<code>etch-ignore</code>、
<code>sid</code>、<code>experimental</code> があります。
<p><a href="Developer#tags">これらの意味</a> については、
バグシステムに関する開発者情報で調べてください。</p></dd>
<dt><code>block</code> <var>バグ番号</var> <code>by</code> <var>バグ</var> ...</dt>
<dd>最初のバグの修正がリストの他のバグによって妨害されていることを記録します。</dd>
<dt><code>unblock</code> <var>バグ番号</var> <code>by</code> <var>バグ</var> ...</dt>
<dd>最初のバグ修正がリストの他のバグによって妨害されていたものが
解除されたことを記録します。</dd>
<dt><code>close</code> <var>バグ番号</var> [ <var>修正されたバージョン</var> ]
(非推奨)</dt>
<dd>
バグ報告 #<var>バグ番号</var> を閉じます。
<p>バグを報告したユーザに通知が送られますが、
(<var>バグ番号</var><code>-done@bugs.debian.org</code>
にメールを送った場合とは異なり)バグを閉じたメールの本文はその通知には
<strong>含まれません</strong>。バグ報告を閉じた担当者は、
別にメッセージを送るなどして、どうしてそのバグが閉じられたのか、
バグを報告したユーザが確実に分かるようにしなければなりません。
こういうわけで、このコマンドの使用は非推奨となっています。
<a href="Developer#closing">バグの正しい閉じ方</a>についての開発者情報を見てください。
</p>
<p><var>修正されたバージョン</var>を指示した場合は、
バグ追跡システムはそのパッケージのそのバージョンで
そのバグが修正されたことを記録します。</p>
</dd>
<dt><code>package</code> [ <var>パッケージ名</var> ... ]</dt>
<dd>以降に続くコマンドが一覧に示したパッケージへのバグにのみ適用されるよう、
制限します。複数のパッケージを指定することも可能です。
パッケージを何も指定しない場合、以降のコマンドは全バグに適用されます。
この機能は誤って間違ったバグ番号を使う可能性に対する保護機能として使うことができます。
<p>使用例:</p>
<pre>
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar sucks
severity 123456 normal
package
severity 234567 wishlist
</pre></dd>
<dt><code>owner</code> <var>バグ番号</var> <var>アドレス</var> | <code>!</code></dt>
<dd><var>アドレス</var> を #<var>バグ番号</var> の「所有者」に設定します。
バグの所有者はその修正に対して責任を負い、関連するメールをすべて受け取ります。
これは、パッケージをチームで管理している場合に、作業を共有するのに便利です。
<p>自分をバグの所有者にしたい場合は、省略形の <code>!</code>
または自分のメールアドレスを指定します。</p>
<dt><code>noowner</code> <var>バグ番号</var></dt>
<dd>バグの通常のメンテナ以外の所有者の情報をすべて消去します。
もしバグに所有者が記録されていなければ、これは何もしません。</dd>
<dt><code>#</code>...</dt>
<dd>一行コメントです。<code>#</code>は行頭になければなりません。
コメント内のテキストは、送信者と関連する担当者への通知に含められるので、
コマンドの理由を示すのに利用できます。</dd>
<dt><code>quit</code></dt>
<dt><code>stop</code></dt>
<dt><code>thank</code></dt>
<dt><code>thanks</code></dt>
<dt><code>thankyou</code></dt>
<dt><code>thank you</code></dt>
<dt><code>--</code></dt>
<!-- #366093, I blame you! -->
<!-- <dt><code>kthxbye</code> -->
<!-- See... I documented it! -->
<dd>各行はどれも空白文字で続けることができます。
制御サーバにメッセージの処理を停止することを伝えます;
メッセージのリマインダとして説明、署名、
その他を記入することができますが、制御サーバには検知されません。</dd>
</dl>
<hr>
#use "otherpages.inc"
#use "$(ENGLISHDIR)/Bugs/footer.inc"
-----------------------------------------------------------------