Re: Bugs/Developer.wml (1.55 -> 1.67)

[SUGIYAMA Tomoaki <tomos@xxxxxxxxxxxxxxxx>]

杉山です。

debian-www: 10420 のパッチをうまく手元で当てられなかったので，
手パッチを当てました。確認していただくと助かります。
＃ commit の際には，さらにタグを小文字に変更し，閉じタグを追加
＃ する予定です。

以下の件についてはどのようにしましょうか?

On Fri, 10 Nov 2006 21:16:01 +0900, KISE Hiroshi wrote:
> 「アーカイブに入る」「アーカイブ入りする」
> 「アーカイブに行く」「アーカイブ行きになる」

> 解決済みのレポートは一定期間後、倉庫行きになってデフォルトでは
> 表示されない、といった見方をしていました。つまり、
> 「このバグは sarge で修正されるまで残ります」
> といった感じ。

> 参考までに。どう表現するかはおまかせします。
> -- 
> 喜瀬“冬猫”浩

--
杉山友章

--------------------------------------------------------------------
#use wml::debian::template title="Debian BTS - 開発者情報" NOHEADER=yes NOCOPYRIGHT=true
#use wml::debian::translation-check translation="1.67"

<H1>バグ処理システムに関する開発者情報</H1>

<P>まず初めに、バグ報告はユーザから通常の電子メールとして
<code>submit@bugs.debian.org</code> に提出されます。このバグ報告は
通し番号が与えられ、 ユーザには受領通知が送られ、
<code>debian-bugs-dist</code> メーリングリストに転送されます。
報告者が <code>Package</code> 行にメンテナのいるパッケージ名を指定した
場合は、該当するメンテナにもその写しが送られます。</P>

<P><code>Subject</code> 行には <code>Bug#</code><var>nnn</var><code>:</code>
が追加されます。<code>Reply-To</code> には、そのバグ報告の提出者と
<var>nnn</var><code>@bugs.debian.org</code> が設定されます。</P>

<hrline>

<ul>
  <li><a href="#closing">バグ報告のクローズ (解決)</a></li>
  <li><a href="#followup">フォローメッセージ</a></li>
  <li><a href="#severities">Severity (重要度) レベル</a></li>
  <li><a href="#tags">バグ報告のタグ</a></li>
  <li><a href="#forward">バグ報告を転送したことの記録</a></li>
  <li><a href="#owner">バグの所有者を変更する</a></li>
  <li><a href="#maintincorrect">パッケージメンテナが間違っている場合</a></li>
  <li><a href="#requestserv">バグを再オープン (reopen)、再指定 (reassign)、操作する</a></li>
  <li><a href="#subscribe">バグ報告を購読する</a></li>
  <li><a href="#subjectscan">廃止されつつあるサブジェクト検査機能</a></li>
  <li><a href="#x-debian-pr"><code>X-Debian-PR: quiet</code> 機能は廃止</a></li>
</ul>

<hrline>


<h2><a name="closing">バグ報告のクローズ (解決)</a></h2>

<p>Debian のバグ報告はその問題が解決したときクローズ (解決) しなければ
なりません。パッケージ中の問題はそのバグの修正を含むパッケージが
Debian アーカイブに入ったときのみ解決したとみなされます。</p>

<p>ふつう、バグ報告をクローズしてよいのはそのバグの報告者とそのバグが
報告されたパッケージのメンテナだけです。この規則には例外があります。
たとえば、不明なパッケージや一般的な擬似パッケージに対するバグなどです。
よく分からないなら、バグ報告をクローズするのではなく、まず debian-devel
メーリングリストで助言を求めましょう。</p>

<p>バグ報告は <var>nnn</var><code>-done@bugs.debian.org</code> に
電子メールを送ることによってクローズしなければなりません。メッセージの
本文はそのバグがどのように修正されたのかの説明を含む必要があります。</p>

<p>バグ追跡システムから受けとった電子メールがあるなら、そのバグ報告を
クローズするにはメールリーダプログラムで返信を作り、<code>To</code> 欄を
編集して、たとえば <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE> のかわりに
<VAR>nnn</VAR><CODE>-done@bugs.debian.org</CODE> を使うだけでいいです
(<var>nnn</var><code>-close</code> は、
<var>nnn</var><code>-done</code> のエイリアスとして用意されています)。</p>

<p>可能なら、
バグ追跡システムがどのリリースのパッケージにその修正が含まれるのか分かるように、
バグを閉じる際のメッセージの<a
href="Reporting#pseudoheader">疑似ヘッダ</a>内に <code>Version</code>
行を書いておいてください。</p>

<p>バグ報告をクローズしようとしている人、それを提出した人および
<code>debian-bugs-closed</code> メーリングリストにそのバグ報告の
ステータスが変更されたことが通知されます。報告の提出者とこの
メーリングリストには <var>nnn</var><code>-done</code> へ送られた
メッセージの内容も送られます。</p>


<h2><a name="followup">フォローメッセージ</a></h2>

<p>バグ追跡システムはバグ報告をフォワードする時に、<code>Reply-To</code>
ヘッダに報告者のメールアドレスとそのバグのメールアドレス
(<var>nnn</var><code>@bugs.debian.org</code>) を含めます。これらは別個のメールアドレスで
あることに注意してください。</p>

<P>クローズされていないバグ報告に開発者が返信したい時は、単にそのバグ報告
に返信します。<code>Reply-To</code> ヘッダをそのまま使うわけです。
これはバグ報告をクローズ<strong>しません</strong>。</p>

<p>バグ追跡システムは、<VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>として受け取った
メッセージをパッケージメンテナに転送し、
バグ報告の追加情報として記録して<code>debian-bugs-dist</code> に転送します。</P>
<P>開発者はバグ報告者へのメールを<VAR>nnn</VAR><CODE>-submiter@bugs.debian.org</CODE>宛に
送信することもできます。</P>

<p>バグ追跡システムは、<VAR>nnn</VAR><CODE>@bugs.debian.org</CODE> として受け取った
メッセージをパッケージメンテナに転送し、
バグ報告の追加情報として記録して <code>debian-bugs-dist</code> に転送します。</P>

<p><var>nnn</var><code>-submitter@bugs.debian.org</code>
にメッセージを送ると、そのバグの報告者に明示的にメールを送り、コピーを
バグ追跡システムに置くことができます。この場合、パッケージメンテナには
メッセージが送られません。</P>

<P><code>debian-bugs-dist</code> には適当でないフォローメッセージ
を送りたい場合、<var>nnn</var><code>-quiet@bugs.debian.org</code> や
<var>nnn</var><code>-maintonly@bugs.debian.org</code> を送信に使うことができます。
<VAR>nnn</VAR><CODE>-quiet@bugs.debian.org</CODE> へのメールは、バグ追跡システムに記録されますが
特定の人やメーリングリストには配送されません。
<VAR>nnn</VAR><CODE>-maintonly@bugs.debian.org</CODE> へのメールは、バグ追跡システムに記録されて
パッケージメンテナだけに配送されます。</P>

<P>もし確固とした受取人変更の意図がないのであれば、メーラーの
`reply to all recipients (すべての受取人に返事をする)' や 
`followup (フォローする)'
の機能を<em>使ってはいけません</em>。特にフォローメッセージを
<code>submit@bugs.debian.org</code> に送らないように注意してください。</P>

<p>受信通知メッセージを抑制するためのヘッダに関する情報や、
バグ追跡システムを使ってカーボンコピーを送る方法については、<a
href="Reporting">バグ報告の説明</a>を見てください。</p>


<h2><A name="severities">Severity (重要度) レベル</A></h2>

<P>バグシステムは、それぞれのバグ報告について severity (重要度) レベルを
記録します。デフォルトでは <code>normal (通常)</code> に設定されますが、
バグ報告の際に疑似ヘッダに <code>Severity</code> 行を入れる
(<A href="Reporting#pseudoheader">Debian にバグを報告する方法</A>
を参照)か、<A href="#requestserv">コントロールリクエストサーバ</A>
に <code>severity</code> コマンドを送ることで変更できます。
複数のタグを指定する場合は、
コンマ、スペース、またはその両方を使って区切ってください。
</P>


<p>severity レベルには以下のものがあります。

<dl>
<dt><code>critical(致命的)</code>
<dd>システム上の関係のないソフトウェア (またはシステム全体) を破壊す
る、重大なデータの欠落を引き起こす、または、そのパッケージをインス
トールしたシステム上でセキュリティホールが生じる場合。

<dt><code>grave (重大)</code>
<dd>問題のあるパッケージが使用できない、またはほとんど使用できない。
またはデータの欠落を引き起こす、そのパッケージを使用するユーザの
アカウントにアクセスを許してしまうセキュリティホールが生じる場合。

<DT><CODE>serious (深刻)</CODE>
<DD><a href="http://release.debian.org/etch_rc_policy.txt";>Debian
ポリシーに対して見すごせない違反</a>がある (大まかに言うと、"must" や
"required" の要件に違反している)、またはパッケージメンテナの意見として
そのパッケージがリリースに適していないと判断された場合。

<dt><code>important (重要)</code>
<dd>バグがパッケージの利用に大きく影響しており、対処しなければ誰にも
まったく使用できない場合。

<dt><code>normal (通常)</code>
<dd>デフォルト値。通常のバグ。

<DT><CODE>minor (軽度)</CODE>
<DD>問題がパッケージの利用に影響しない、かつ修正はたいした事が
ないと思われる場合。
 
<dt><code>wishlist (要望)</code>
<dd>将来的な要望、主に設計上の理由により修正が非常に困難なバグ。
</dl>

<p><em><a href="http://bugs.debian.org/release-critical/";>リリース
クリティカル</a></em>とみなされる重要度があります。これはそのバグが
そのパッケージを Debian の安定版でリリースするのに影響があるという意味です。
現在、<strong>critical</strong>、<strong>grave</strong>
そして <strong>serious</strong> がこれに該当します。
これらの深刻度がもたらすいかなる問題についての完全で正式なルールは、<a
href="http://release.debian.org/etch_rc_policy.txt";>Etch
のリリースクリティカル問題</a>のリストを見てください。</p>

<H2><a name="tags">バグ報告のタグ</a></H2>

<p>それぞれのバグ報告は規定されたタグをつけることができます。
これらのタグは、パッケージのページやすべてのバグの記録を閲覧した
ときに、バグ報告のリストのなかに表示されます。

<p>タグは、バグの報告時に擬似ヘッダに <code>Tags</code> 行を指定すること
(<a href="Reporting#pseudoheader">バグ報告の勧め (使用説明書)</a> を参照)
や、<a href="#requestserv">コントロールリクエストサーバ</a>に対して
<code>tags</code> コマンドを用いることで設定することができます。

<p>現在のバグのタグは以下のものがあります。

<dl>

<dt><code>patch (パッチ)</code>
  <dd>バグ報告に、バグを修正するためのパッチや簡単な手順が含まれています。
  パッチがあってもバグを適切に解決できない場合や別の問題を生じる場合は、
  このタグは使うべきではありません。

<dt><code>wontfix (修正予定無)</code>
  <dd>このバグは修正されないでしょう。バグ修正に任意の 2 種類の選択肢が
  あってメンテナと報告者がそれぞれ異なる方法を望んでいる場合や、修正
  することによってより悪い問題が生じる場合や、その他の理由があるでしょう。

<dt><code>moreinfo (追加情報)</code>
  <dd>このバグは報告者が詳細情報を提供しないかぎり特定できません。
  報告者が適当な期間 (数ヶ月) 中に詳細情報を提供しなければ、バグはクローズ
  されるでしょう。これは、「動きません」というようなバグ報告のためにあります。
  何が動かないのでしょう?

<dt><code>unreproducible (再現不可能)</code>
  <dd>このバグはメンテナのシステムでは再現できなかったものです。
  問題の原因調査のために、第三者の協力が必要とされています。

<dt><code>help (助けを求む)</code>
  <dd>メンテナは、このバグを処理するのに助けを必要としています。

<dt><code>pending (保留)</code>
  <dd>バグの解決法が発見され、まもなくアップロードが行なわれます。

<dt><code>fixed (修正済)</code>
  <dd>(例えばノンメンテナ・アップロードのおかげなどで) このバグは修正されたか
  うまく動くようになりましたが、解決のために必要な事項がまだ残っています。
  かつての "fixed" severity (重要度) はこのタグに置き換えられました。

<dt><code>security (セキュリティ)</code>
  <dd>このバグはパッケージのセキュリティ問題を説明します
  (例: アクセスされてはいけないデータへのアクセスを許可する不正な
  許可属性がある、やれるべきではない方法でシステムを制御できるバッファ
  オーバーフローがある、修正すべき DoS 攻撃の穴がある、等)。
  ほとんどのセキュリティバグは、critical (致命的) や grave (重大) の severity
  (重要度) も設定すべきです。

<dt><code>upstream (上流)</code>
  <dd>このバグは、パッケージの上流の部分に影響します。

<dt><code>confirmed (確認済)</code>
  <dd>メンテナはこのバグを読み、理解し、その内容に基本的に合意しましたが、
  まだ修正していません。(このタグの使用はできるだけ控えてください。
  大量の未解決バグに対処しなければならないメンテナが使うことを
  想定したタグです。)

<dt><code>fixed-upstream (上流で解決済)</code></dt>
  <dd>このバグは、上流メンテナによって修正されましたが、
  まだパッケージにはなっていません (何らかの理由で:
  たとえば、変更が複雑すぎてバックポートできないとか、
  あまりに些細なので無視しているとか)。

<dt><code>fixed-in-experimental (experimental で解決済)</code></dt>
  <dd>このバグは experimental ディストリビューションのパッケージで
  修正されていますが、unstable ディストリビューションではまだです。

<dt><code>d-i (インストーラ)</code>
  <dd>このバグは、debian-installer に関するものです。
  インストーラの開発に関係するけれども、インストーラの直接の
  構成要素ではないパッケージに対するバグの場合、このタグを使ってください。

<dt><code>ipv6</code>
  <dd>このバグは、インターネットプロトコル v6 (IPV6)
  のサポートに関係します。

<dt><code>lfs (巨大ファイルサポート)</code>
  <dd>このバグは、大きなファイル (2 ギガバイトを超える)
  のサポートに関係します。

<dt><code>l10n</code>
  <dd>このバグは、パッケージの地域化に関するものです。

<dt><code>potato</code>
  <dd>このバグは特に Debian の potato リリースに加えられるものです。

<dt><code>woody</code>
  <dd>このバグは特に woody ディストリビューション
  に加えられるものです。

<dt><code>sarge</code>
  <dd>このバグ報告は sarge で修正されるまでアーカイブに入りません。

<dt><code>sarge-ignore (sarge では無視)</code></dt>
  <dd>このリリースクリティカルバグは、sarge
  のリリースの目的のために、無視されます。
  <strong>このタグは、リリースマネージャだけが使うべきものです。
  リリースマネージャからの明示的な許可がない限りは使わないでください。</strong>

<dt><code>etch</code>
  <dd>このバグ報告は etch で修正されるまでアーカイブに入りません。

<dt><code>etch-ignore</code>
  <dd>このリリースクリティカルバグは、etch
  のリリースの目的のために、無視されます。
  <strong>このタグは、リリースマネージャだけが使うべきものです。
  リリースマネージャからの明示的な許可がない限りは使わないでください。</strong>

<dt><code>sid</code>
  <dd>このバグ報告は sid で修正されるまでアーカイブに入りません。

<dt><code>experimental</code>
  <dd>このバグ報告は experimental で修正されるまでアーカイブに入りません。

</dl>

<p>最近、最後の 6 つのタグの意味が変わりました。ignore
タグは testing への移行という目的のために、そのバグを無視します。
リリースタグは、以前はどのバグがどのリリースに影響するかを意味するものでしたが、
現在はバグがいつアーカイブされるのかを意味します。</p>

<h2><A name="forward">バグ報告を転送したことの記録</A></h2>

<P>Debian パッケージの元である上流ソースパッケージの開発者に
Debian パッケージ開発者からバグ報告を転送する際は、バグ追跡システム
に次のようにして記録しなければなりません。</P>

<P>あなたのメッセージの <code>To</code> フィールドには原作者達の
アドレスのみが書かれていることを確認すること。そして、
<code>CC</code> フィールドにはバグを報告した人と
<var>nnn</var><code>-forwarded@bugs.debian.org</code>
そして <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE> を入れること。</P>

<P>原作者が返信をする際に、<code>CC</code> に
<var>nnn</var><code>-forwarded@bugs.debian.org</code> を残すように依頼すること。
バグ追跡システムはこの返信を元々のバグ報告とともに保存します。
この場合、メッセージの保存はしますが送信はしません。
通常のようにメッセージを
送信するには <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>
に送ってください。</P>

<P>バグがすでに転送済であると記録されていない場合、バグ追跡システムが 
<var>nnn</var><code>-forwarded</code> でメッセージを受け取ると、その
メッセージは <code>To</code> フィールドにあるアドレスに転送済である
ことを該当するバグに記録します。</P>

<P><A href="server-control"><code>control@bugs.debian.org</code></A> 
にメッセージを送ることで、`forwarded to' 情報を操作することができます。</P>


<h2><a name="owner">バグの所有者を変更する</a></h2>

<p>バグを修正する責任を持った人が、
関連するパッケージのメンテナには割り当てられていない場合
(例えば該当するパッケージがチームでメンテナンスされている場合など)、
このことをバグ追跡システムに記録しておくと役に立つでしょう。
そのため、それぞれのバグは任意に所有者を持てるようになっています。</p>

<p>バグの所有者は、バグ報告時に疑似ヘッダに <code>Owner</code>
行を付けたり (<a href="Reporting#pseudoheader">バグ報告の説明</a>を参照)、
<a href="#requestserv">コントロールリクエストサーバ</a>に <code>owner</code>
や <code>noowner</code> のコマンドを使って設定できます。</p>


<H2><a name="maintincorrect">パッケージメンテナが間違っている場合</a></H2>

<p>パッケージメンテナが間違っている場合、多くの原因は最近
メンテナが交替されていて、新メンテナが control ファイルの
<code>Maintainer</code> フィールドを更新した新しいパッケージを
アップロードしていないためです。これは、パッケージをアップロード
することにより修正されます。これ以外に、アーカイブメンテナが
パッケージに記録されているメンテナを無視するように設定する
ことが可能です。これは例えば、すぐにパッケージの再構築、再アップロードの必要
がないと思われる場合に利用します。override file を変更するには
<code>override-change@debian.org</code> に連絡してください。</P>


<h2><A name="requestserv">バグを再オープン (reopen)、再指定 (reassign)、操作する</A></h2>

<P>別のパッケージにバグ報告を再指定 (reassign) する事や、
誤ってクローズしてしまったバグを再オープン (reopen) する事、
バグ報告が転送されている送付先について述べている情報を修正する事、
バグ報告の severity (重要度) やタイトルを変更する事、バグの所有者を設定する事、
バグ報告のマージ (merge)・マージ解除 (unmerge) をする事、
バグが発見された・修正されたパッケージのバージョンを記録する事ができます。
これらの操作は、<code>control@bugs.debian.org</code> にメールを
送ることにより行います。</P>

<P><A href="server-control">これらのメッセージの書式</A> は
WWW 上で利用できる別の文書や <code>bug-maint-mailcontrol.txt</code> 
ファイルに記述されています。テキストバージョンは、上記のアドレスのサー
バに <code>help</code> と書いたメールを送ることで入手することも可能です。</P>

<h2><a name="subscribe">バグ報告を購読する</a></h2>

<p>バグ追跡システムでは、バグの報告者、開発者およびそれに関心のある第三者が、
個々のバグ報告を購読できます。あるバグに注意を払い続けたい場合、<a
href="http://packages.qa.debian.org";>PTS</a> を通してパッケージの購読をしなくても、
この機能を利用できます。<var>nnn</var><code>@debian.org</code>
に届いたすべてのメッセージは購読者に送られます。</p>

<p>nnn のバグ報告を購読するには、<var>nnn</var><code>-subscribe@bugs.debian.org</code>
にメールを送ります。メールの件名、本文は BTS によって無視されます。
このメールが処理されると、そのバグに関するメッセージを受け取れるようにしたい
場合はこれに返信してください、という内容の確認メッセージがユーザに届きます。</p>

<p>購読を停止することも可能です。購読を止めるには
<var>nnn</var><code>-unsubscribe@bugs.debian.org</code> へメールを送ります。
この場合も、メールの件名、本文は BTS によって無視されます。
購読を止めるための確認メッセージが届きますので、それに返信する必要があります。</p>

<p>通常、購読に使用されるメールアドレスは <code>From</code> ヘッダに書かれている
ものになります。別のメールアドレスで購読したいなら、購読に使用するメールアドレス
を符号化して購読メッセージの宛先に埋め込む必要があります。
<var>nnn</var><code>-subscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>
という形式になります。
この例では、バグ <var>nnn</var> の購読メッセージを <code>localpart@example.com</code>
へ送ります。<code>@</code> 記号を <code>=</code> 記号に置き換えて符号化
しなければなりません。同様に、購読を止める場合も、
<var>nnn</var><code>-unsubscribe-</code><var>localpart</var><code>=</code><var>example.com</var><code>@bugs.debian.org</code>
という形式になります。
どちらのケースでも、メールの件名と本文は確認のリクエストに含めて、
そのメールアドレスに転送されます</p>

<h2><a name="subjectscan">廃止されつつあるサブジェクト検査機能</a></h2>

<P>サブジェクトが <code>Bug#</code><var>nnn</var> で始まるメッセージが
<code>submit</code> や <code>bugs</code> に到着した場合、この
メッセージは <var>nnn</var><code>@bugs.debian.org</code> に送付済であるとして
扱われます。これは、昔のアドレスから転送されたメールと互換性を残すためと、
誤って (例えば、全ての受取人へ返信をしてしまうことにより)
<code>submit</code> に送られたフォローメールを捕えるためです。</P>

<P><code>maintonly</code>、<code>done</code>、<code>quiet</code>、
<code>forwarded</code> についても同様に扱われます。これらのアドレスでは、
サブジェクトタグのあるメールは対応する 
<var>nnn-whatever</var><code>@bugs.debian.org</code> アドレスには送付済であると
して扱われます。</P>

<P><code>forwarded</code> と <code>done</code> に届いたタグのない
メッセージ (例えばアドレスにバグ番号がないもの) で、
サブジェクトにバグ番号がついていないメッセージ
は 'junk' として記録され数週間保存はされますが、それ以外の処理は
無効となります。</P>

<h2><a name="x-debian-pr"><code>X-Debian-PR: quiet</code> 機能は廃止</a></h2>

<P>バグ追跡システムが <code>debian-bugs</code> で受け取った
メッセージをどこにも転送させないようにするためには、従来は
実際のメールヘッダに <code>X-Debian-PR: quiet</code> 行を入れていました。</P>

<P>現在、このヘッダ行は無視されます。代わりに、
<code>quiet</code> や <var>nnn</var><code>-quiet</code> (もしくは、
<code>maintonly</code> や <var>nnn</var><code>-maintonly</code>)
にメッセージを送ってください。</P>

<hr>

#use "otherpages.inc"

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