path: root/japanese/Bugs/server-control.wml

#use wml::debian::template title="Debian BTS — 制御サーバ" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="d11193e66dd678156a1f8aa4c02b5ec7ae7eb116"
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"

<h1>バグ制御とメールサーバの操作</h1>

<p><code>request@bugs.debian.org</code> を利用して<a
href="server-request">バグデータや説明をメールで取得できる</a>のと同様、
<code>control@bugs.debian.org</code>
を利用してバグ報告を様々な方法で操作することができます。</p>

<p>制御サーバはコマンドが追加されていますが、
リクエストサーバと同じように動作します &mdash; 実のところ同一のプログラムです。
単に情報を取得する際にミスで問題を起こすのを避けるためだけの目的でこの
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>

  <table style="margin-left:auto;margin-right:auto">
    <tr>
    <td align="center">一般</td>
    <td align="center">バージョン管理</td>
    <td align="center">複製</td>
    <td align="center">その他</td>
    </tr>
    <tr>
      <!-- 一般 -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#reassign">reassign</a></li>
	  <li><a href="#severity">severity</a></li>
	  <li><a href="#tag">tags</a></li>
	  <li><a href="#retitle">retitle</a></li>
	  <li><a href="#submitter">submitter</a></li>
	  <li><a href="#affects">affects</a></li>
	  <li><a href="#summary">summary</a></li>
	  <li><a href="#outlook">outlook</a></li>
	</ul>
      </td>
      <!-- バージョン管理 -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
	  <li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li>
	  <li><a href="#reopen">reopen</a></li>
	  <!-- <dt>(close)</dt> Deprecated -->
	</ul>
      </td>
      <!-- 複製 -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
	  <li><a href="#forcemerge">forcemerge</a></li>
	  <li><a href="#clone">clone</a></li>
	</ul>
      </td>
      <!-- その他 -->
      <td valign="top">
	<ul class="nodecoration">
	  <li><a href="#thanks">thanks</a></li>
	  <li><a href="#comment">#</a></li>
	  <li><a href="#forwarded">forwarded</a> |  <a href="#notforwarded">notforwarded</a></li>
	  <li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li>
	  <li><a href="#block">block</a> | <a href="#unblock">unblock</a></li>
	  <li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
          <li><a href="server-request#user">user</a> |
            <a href="server-request#usertag">usertag</a> |
            <a href="server-request#usercategory">usercategory</a></li>
	</ul>
      </td>
    </tr>
  </table>

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

<p><var>バージョン</var>が指示された場合は、バグ追跡システムはそのバグが
新しく割り当てられたパッケージのそのバージョンに影響することを記録します。</p>

<p>コンマ区切りでパッケージ名を連ねれば、2
つのパッケージに同時にバグを割り当てることが可能です。
<em>しかし</em>、そのようにするのは、
<em>一方の</em>パッケージを変更すればそのバグが解決できる場合のみにしてください。
そうでない場合は、バグ報告を<a href="#clone">複製</a>し、
複製によって新たにできたバグをもう一方のパッケージに割り当て直してください。</p>
</dd>


<dt><a name="reopen"><code>reopen</code> <var>バグ番号</var>
 [ <var>報告者アドレス</var> | <code>=</code> | <code>!</code> ]</a></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var>が閉じられている場合、再開し、修正済みバージョンの情報を削除します。</p>

<p>デフォルトあるいは <code>=</code>
を指定した場合、元の報告者がそのままこの報告の報告者となり、
再び閉じられる時に通知を受け取ることになります。</p>

<p><var>報告者アドレス</var>を指定した場合、
そのアドレスが報告者としてセットされます。
自分を再開したバグの新しい報告者にする場合は、短縮形の <code>!</code>
を使用するか、自分のメールアドレスを指定してください。</p>

<p>通常は元々の報告者に
自分がそのバグ報告を再開しようとしていることを連絡すると良いでしょう。
それによって、再びバグが閉じられた時に通知を受け取ることが期待できます。</p>

<p>バグが閉じられていない場合、reopen
は何もせず、報告者の変更も行いません。未解決バグの報告者を変更するには、
<code>submitter</code> コマンドを使います。
このコマンドを使うと元々の報告者に通知されることに注意してください。</p>

<p>バグがそのパッケージの特定のバージョンで一旦閉じられてから、
以降のバージョンで再発した場合は、代わりに
<code>found</code> コマンドを使用してください。</p>
</dd>


  <dt><a name="found"><code>found</code> <var>バグ番号</var> [ <var>バージョン</var> ]</a></dt>
  <dd>
    <p>
    #<var>バグ番号</var>が割り当てられているパッケージの指定された
    <var>バージョン</var>で発生したことを記録します。
    <var>バージョン</var>は完全修飾の
    <var>ソースパッケージ名/バージョン</var>の表記も使えます。
    </p>

<p>バグ追跡システムはこの情報とバグを閉じるときに記録するバージョンを合わせて利用して、
それぞれのパッケージの複数のバージョンに対するバグの状況を示します。
修正されたバージョンが存在しない、
あるいは修正の後に再現されたものは未解決と見なします。</p>

    <p>
    <var>バージョン</var>が指定されない場合は、
    そのバグの修正されたバージョンのリストがクリアされます。これは
    <code>reopen</code> と同じ事になります。
    <var>バージョン</var>は完全修飾の
    <var>ソースパッケージ名/バージョン</var>の表記も使えます。
    </p>

    <p>
    このコマンドは、バージョンが指定されていない場合、または発生 (found)
    の印をつけられた<var>バージョン</var>が最後に修正 (fixed)
    の印をつけられた最大の<var>バージョン</var>以上である場合、
    バグに未解決の印をつけるだけです。
    (未解決の印をバグにつけたいのだと自分で確信している場合は、<code>found</code>
    とともに <code>reopen</code> を使用してください。)
    </p>

<p><code>reopen</code>
の書式で<var>バージョン</var>を追加するのが苦痛となっていることから、
このコマンドが導入されました。</p>
</dd>


  <dt><a name="notfound"><code>notfound</code> <var>バグ番号</var> <var>バージョン</var></a></dt>
  <dd>
    <p>#<var>バグ番号</var>が割り当てられているパッケージの指定された
    <var>バージョン</var>で見つかったという記録を削除します。
    <var>バージョン</var>は完全修飾の
    <var>ソースパッケージ名/バージョン</var>の表記も使えます。
    </p>

<p>これはそのバージョンで修正済みとしてバグを閉じるのとは異なり、
そのバグがどちらのバージョンでも修正済みにはなりません
&mdash; そのバージョンに対する情報はなくなります。
これはバグが見つかった記録の誤りの修正に向いています。</p>
</dd>


  <dt><a name="fixed"><code>fixed</code> <var>バグ番号</var> <var>バージョン</var></a></dt>
  <dd>
    <p>バグ報告 #<var>バグ番号</var> が、それが割り当てられた
    パッケージの指定の<var>バージョン</var>で修正済みであることを示します。
    <var>バージョン</var>は完全修飾の
    <var>ソースパッケージ名/バージョン</var>の表記も使えます。
    </p>

<p>これは、バグを閉じたものとして印をつけることは<em>行わず</em>、
単にバグが修正された特定のバージョンを追加するだけです。
バグを閉じて特定のバージョンで修正された印をつけるには、
バグ番号-done アドレスを利用してください。</p>
</dd>


<dt><a name="notfixed"><code>notfixed</code> <var>バグ番号</var> <var>バージョン</var></a></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var>が指定の<var>バージョン</var>
で修正されたという記録を削除します。</p>

    <p>このコマンドは、<code>notfound</code> と同様に <code>found</code>
    と等価です (found は特定のバージョンでの fixed を削除し、notfound
    は found を削除します)。found のバージョンが既存のどの fixed
    バージョンよりも大きい場合は例外で reopened とはなりません。
    これを使うのは、バグを fixed としたときの誤りを修正する場合です。
    ほとんどの場合 <code>notfixed</code> ではなく <code>found</code>
    を使います。</p>
</dd>


<dt><a name="submitter"><code>submitter</code> <var>バグ番号</var>
<var>報告者アドレス</var> | <code>!</code></a></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var>の報告者を<var>報告者アドレス</var>
に変更します。</p>

<p>自分を新しい報告者にしたい場合は、短縮形の <code>!</code>
を使うか、自分のメールアドレスを指定してください。</p>

<p><code>reopen</code>
コマンドが再開の対象となるバグに結合されたバグの報告者も変更するのに対して、
<code>submitter</code> では結合されたバグを変更しません。</p>
</dd>


<dt><a name="forwarded"><code>forwarded</code> <var>バグ番号</var> <var>アドレス</var></a></dt>
<dd>
<p><var>バグ番号</var>が<var>アドレス</var>で示す、
上流の保守担当者に転送されることに注意してください。
これは実際の転送は行いません。これは誤った forwarded-to
アドレスの変更や、これまでに転送されてきたものではない、
新しいアドレスを記録するのに使います。<var>アドレス</var>は一般に URI
あるいはメールアドレスであるべきです。URI を使うと、リモートのバグ追跡システム
(bugzilla など) にバグの状態をツールで照会できます。
</p>

<p>
使用例:
</p>

  <pre>
  forwarded 12345 http://bugz.illa.foo/cgi/54321
  </pre>
</dd>


<dt><a name="notforwarded"><code>notforwarded</code> <var>バグ番号</var></a></dt>
<dd>
<p><var>バグ番号</var>を転送していた上流の保守担当者の情報を抹消します。
バグ報告の転送記録がない場合は何も行いません。</p>
</dd>


<dt><a name="retitle"><code>retitle</code> <var>バグ番号</var> <var>新しい題名</var></a></dt>
<dd>
<p>指定したバグ報告の題名を変更します (元々のバグ報告のメールヘッダの
<code>Subject</code> がデフォルトとなります)。
また、このバグが結合された全バグ報告の題名についても変更されます。</p>
</dd>


<dt><a name="severity"><code>severity</code> <var>バグ番号</var> <var>重要度 (severity)</var></a></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var> の重要度レベルを <var>severity</var>
に設定します。バグを報告したユーザには通知されません。</p>

<p>重要度には <bts_severities> があります。</p>

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

  <dt><a name="affects"><code>affects</code> <var>バグ番号</var>
      [ <code>+</code> | <code>-</code> | <code>=</code>
      ] <var>パッケージ</var> [ <var>パッケージ</var> ... ]</a></dt>
  <dd>
    <p>
      バグが他のパッケージに影響を及ぼすことを示します。
      実際のバグは割り当てられているパッケージに存在するけれども、
      <var>バグ番号</var>により<var>パッケージ</var>で問題が発生する場合、
      <var>パッケージ</var>のバグリストにデフォルトでそのバグが
      リストされることになります。ユーザからの複数の報告が誤った
      パッケージに割り当てられるような状況が非常に深刻な場合に
      これを使います。<code>=</code> は指定されたパッケージリストに
      影響があることを示し、これがパッケージリストが指定されない場合の
      既定の動作となります。<code>-</code> は指定されたパッケージを
      影響するパッケージのリストから削除します。<code>+</code>
      は指定されたパッケージを影響するパッケージのリストに追加します。
      これがパッケージが指定された場合の既定の動作になります。
    </p>
  </dd>

  <dt><a name="summary"><code>summary</code> <var>バグ番号</var>
      [<var>メッセージ番号</var> | <var>サマリー本文</var>]</a></dt>
  <dd>
    <p>
      バグのサマリーとして使うメッセージを選択します。
      ヘッダや制御ではないと判定した最初の段落を解析してバグのサマリーにセットし、
      それがバグ報告ページの一番上に表示されます。
      元の報告で問題がうまく説明されていない、
      あるいはバグへのメッセージが多くなり実際の問題の把握が難しくなった、
      という場合に有用です。
    </p>

    <p>
      <var>メッセージ番号</var>が指定されていない場合はサマリーは消えます。
      <var>メッセージ番号</var>はバグ報告の cgi
      スクリプトの出力にあるメッセージ番号です。<var>メッセージ番号</var>として
      0 を指定すると現在のメッセージを使用します
      (つまり、control@bugs.debian.org に送られた、
      サマリー制御コマンドを含むメッセージ)。
    </p>
    <p>
      <var>メッセージ番号</var>が数値や空白文字列ではない場合は、
      それをサマリーにセットする文だと想定します。
    </p>
  </dd>

  <dt><a name="outlook"><code>outlook</code> <var>バグ番号</var>
      [<var>メッセージ番号</var> | <var>見通し文</var>]</a></dt>
  <dd>
    <p>
      バグの修正の見通し (またはバグ修正の現状)
      として使用するメッセージを選択します。
      メッセージの最初に現れる非疑似ヘッダ/非制御項目が解析され、
      バグの見通しにセットされてバグ報告ページの最上部に表示されます。
      これは (例えばバグ退治パーティで)
      共にこのバグの修正にあたっている他の人との調整に便利です。
    </p>
    <p>
      <var>メッセージ番号</var>が指定されない場合、
      見通しはクリアされます。<var>メッセージ番号</var>はバグ報告 cgi
      スクリプトの出力に表示されるメッセージ番号です;
      <var>メッセージ番号</var>に 0 を指定するとこのメッセージ
      (つまり outlook 制御コマンドを記述して control@bugs.debian.org
      宛に送られたメッセージ) が使われます。
    </p>
    <p>
      <var>メッセージ番号</var>が数値や空白文字列ではない場合は、
      それを見通しにセットする文だと想定します。
    </p>
  </dd>


<dt><a name="clone"><code>clone</code> <var>バグ番号</var> <var>新 ID</var> [ <var>新 ID</var> ... ]</a></dt>
<dd>
<p>clone 制御コマンドによりバグ報告を複製することができます。
これは、一つの報告が実際には複数のバグを指摘しているような場合に便利です。
「<var>新 ID</var>」はスペース区切りのマイナスの数値で、
以降のコマンドから新しく複製されたバグを参照するのに使うことができます。
新しいバグ報告は、それぞれの「新 ID」に対して作成されます。</p>

<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><a name="merge"><code>merge</code> <var>バグ番号</var> <var>バグ番号</var> ...</a></dt>
<dd>
<p>複数のバグ報告を結合します。バグ報告が結合されると、
結合されたバグ報告の任意の一つに対してオープン、クローズ、
転送済としてマーク、マーク解除、新しいパッケージの再指定の場合に、
結合されたバグ報告すべてに対して同じ操作が行なわれます。</p>

<p>バグ報告を結合する場合には、それらが厳密に同じ状態でなければなりません:
バグがすべてオープンであるかクローズで、
すべて同じ上流担当者のアドレスに転送、あるいは未転送になっていて、
バグがすべて同じパッケージ (群) を対象としていて
(バグが対象としているパッケージについて完全な文字列比較が行われます)、
バグがすべて同じ重要度 (severity) になっていないといけません。
対象のバグが同じ状態でない場合、<code>merge</code>
コマンドを使用する前に、<code>reassign</code>、<code>reopen</code>
等を使って同じ状態にしなければなりません。
タイトルが一致している必要はなく、結合により影響を受けることもありません。
同様にタグも影響を受けません。それらは結合されます。</p>

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

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

<p>結合されたバグ報告は、バグ報告それぞれの抹消期限がすべて満了した後で、
すべて同時に抹消されます。</p></dd>


<dt><a name="forcemerge"><code>forcemerge</code> <var>バグ番号</var> <var>バグ番号</var> ...</a></dt>
<dd>
<p>複数のバグ報告を強制的に結合します。
通常の結合 (merge) においては設定が一致していなければなりませんが、
こちらではリストの先頭のバグの設定が以降のバグに割り当てられます。
誤記による誤った結合を防ぐため、
バグはすべて同じパッケージのものでなければなりません。
結合が意味することについては上記の説明文を参照してください。</p>

<p>これを使うと結合でバグを閉じることができるということに注意してください
&mdash; これを行う場合は、
閉じるにあたって適切なメッセージを報告者に通知する責任があります。</p>
</dd>


<dt><a name="unmerge"><code>unmerge</code> <var>バグ番号</var></a></dt>
<dd>
<p>指定したバグ報告を、これに結合されていた他のバグ報告から分離します。
指定したバグ報告が複数のバグ報告に結合されていた場合は、
指定したバグ報告以外はすべて結合されたままとなります
&mdash; 明示的に指定したバグのみが結合を解除されます。</p>

<p>多くのバグ報告が一つに結合されているのを二つのグループに分けたい場合は、
新しいグループに移したいバグ報告をそれぞれ個別に分離し、
それから新しいグループに結合しなければなりません。</p>

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


  <dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>バグ番号</var> [ <code>+</code> |
    <code>-</code> | <code>=</code> ] <var>タグ</var> [ <var>タグ</var> ... ]
    [ <code>+</code> | <code>-</code> | <code>=</code> <var>tag</var> ... ] ]</a></dt>
  <dd>
    <p>バグ報告 #<var>バグ番号</var> にタグを設定します。
    バグの報告者には通知されません。<code>+</code> はそれに続く<var>タグ</var>
    をそれぞれ追加、<code>-</code> はそれに続く<var>タグ</var>をそれぞれ削除、
    <code>=</code>はそれに続くタグを新しく付けなおすことをそれぞれ意味します。
    <code>+</code>, <code>-</code>, あるいは <code>=</code>
    が間にある場合はそれに続くタグへの動作を変更します。
    デフォルトの動作は追加です。</p>

<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

        \# 'moreinfo' タグを削除して 'patch' タグを追加
        tags 123456 - moreinfo + patch
</pre>

<p>現在、有効なタグには <bts_tags> があります。</p>

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


<dt><a name="block"><code>block</code> <var>バグ番号</var> <code>by</code> <var>バグ</var> ...</a></dt>
<dd>
<p>最初のバグの修正がリストの他のバグによって妨害されていることを記録します。</p>
</dd>


<dt><a name="unblock"><code>unblock</code> <var>バグ番号</var> <code>by</code> <var>バグ</var> ...</a></dt>
<dd>
<p>最初のバグ修正がリストの他のバグによって妨害されていたものが
解除されたことを記録します。</p>
</dd>


<dt><a name="close"><code>close</code> <var>バグ番号</var> [ <var>修正されたバージョン</var> ]
 (非推奨)</a></dt>
<dd>
<p>バグ報告 #<var>バグ番号</var> を閉じます。</p>

<p>バグを報告したユーザに通知が送られますが、
(<var>バグ番号</var><code>-done@bugs.debian.org</code>
にメールを送った場合とは異なり) バグを閉じたメールの本文はその通知には
<strong>含まれません</strong>。バグ報告を閉じた担当者は、
別にメッセージを送るなどして、どうしてそのバグが閉じられたのか、
バグを報告したユーザが確実に分かるようにしなければなりません。
こういうわけで、このコマンドの使用は非推奨となっています。
<a href="Developer#closing">バグの正しい閉じ方</a>についての開発者情報を見てください。</p>

<p><var>修正されたバージョン</var>を指示した場合は、
バグ追跡システムはそのパッケージのそのバージョンで
そのバグが修正されたことを記録します。</p>
</dd>


<dt><a name="package"><code>package</code> [ <var>パッケージ名</var> ... ]</a></dt>
<dd>
<p>以降に続くコマンドが一覧に示したパッケージへのバグにのみ適用されるよう、
制限します。複数のパッケージを指定することも可能です。
パッケージを何も指定しない場合、以降のコマンドは全バグに適用されます。
この機能は誤って間違ったバグ番号を使う可能性に対する保護機能として使うことができます。</p>

<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><a name="owner"><code>owner</code> <var>バグ番号</var> <var>アドレス</var> | <code>!</code></a></dt>
<dd>
<p><var>アドレス</var> を #<var>バグ番号</var> の「所有者」に設定します。
バグの所有者はその修正に対して責任を負います。
これは、パッケージをチームで管理している場合に、作業を共有するのに便利です。</p>

<p>自分をバグの所有者にしたい場合は、省略形の <code>!</code>
または自分のメールアドレスを指定します。</p>


<dt><a name="noowner"><code>noowner</code> <var>バグ番号</var></a></dt>
<dd>
<p>バグの通常のメンテナ以外の所有者の情報をすべて消去します。
もしバグに所有者が記録されていなければ、これは何もしません。</p>
</dd>


<dt><a name="archive"><code>archive</code> <var>バグ番号</var></a></dt>
<dd>
<p>バグがアーカイブの要件を満たしている場合、
過去のある時点でアーカイブされたけれども現在はアーカイブされていないそのバグを、時間を無視してアーカイブします。</p>


<dt><a name="unarchive"><code>unarchive</code> <var>バグ番号</var></a></dt>
<dd>
<p>過去にアーカイブされたバグのアーカイブを解除します。
アーカイブ解除は、一般に、適切な reopen および found/fixed と
組み合わせられるべきです。
アーカイブ解除されたバグは、時間ベースではないアーカイブ要件を
満たすと仮定して、archive を使ってアーカイブできます。
報告者の変更のような些細な変更をアーカイブされたバグに加えるために
アーカイブ解除を使うべきではありません。アーカイブ解除の本来の目的は BTS
管理者の手に拠らずアーカイブされたバグを再開できるようにすることです。</p>


<dt><a name="comment"><code>#</code>...</a></dt>
<dd>
<p>一行コメントです。<code>#</code>は行頭になければなりません。
コメント内のテキストは、送信者と関連する担当者への通知に含められるので、
コマンドの理由を示すのに利用できます。</p>
</dd>


<dt><a name="thanks"><code>quit</code></a></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>
<p>各行はどれも空白文字で続けることができます。
制御サーバにメッセージの処理を停止することを伝えます
&mdash; メッセージのリマインダとして説明、署名、
その他を記入することができますが、制御サーバには検知されません。</p>
</dd>
</dl>

<hr />

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"