Bugs/Developer 1.32 (Re: Debian Web site Translation Update)

[Fumitoshi UKAI <ukai@debian.or.jp>]

At Sun, 27 Jan 2002 22:11:53 +0900,
ukai@debian.or.jp wrote:
> 
> NeedToUpdate	Bugs/Developer	1.23	1.32

Bugs/Developer はこんなかんじでしょうか。

-- 
鵜飼文敏

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

<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="#maintincorrect">パッケージメンテナが間違っている場合</a></li>
  <li><a href="#requestserv">バグを再オープン(reopen)、再指定(reassign)、操作する</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>A developer who receives a bug from the tracking system, or sees it on
-<CODE>debian-bugs-dist</CODE>, and takes
-responsibility for it should hit Reply in their favourite mailreader,
-and then edit the <CODE>To</CODE> field to say

<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</code> のかわりに、
<var>nnn</var><code>-done@bugs.debian.org</code> に書き換えて
メールをおくります (<var>nnn</var><code>-close</code> は、
<var>nnn</var><code>-done</code> のエイリアスとして用意されています)。
</P>

<p>バグをクローズした人とバグを報告した人、<code>debian-bugs-closed</code>
メイリングリストに、そのバグ報告のステータスが変化されたことが通知を
されます。報告者とメイリングリストは<var>nnn</var><code>-done</code>に送られた
メールの内容もうけとります。</p>

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

<P>バグ追跡システムはバグ報告を転送する時に、バグ報告の元々の提出者の
アドレスとバグ報告のアドレス(<var>nnn</var><code>@bugs</code>)を
<code>To</code> 行に含めます。この二つのアドレスは別のものであることに
注意してください。</P>

<p>バグ報告に開発者が返信したい時は、単にそのバグ報告
に返信します (この場合はバグがクローズされたとは<b>記録されません</b>)。</p>

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

<P>開発者はバグ報告者へのメールを<var>nnn</var><code>-submiter@bugs</code>宛に
送信することもできます。</P>

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

<P>もし確固とした受取人変更の意図がないのであれば、メーラーの
`reply to all recipients(すべての受取人に返事をする)' や 
`followup(フォローする)'
の機能を<em>使ってはいけません</em>。特にフォローメッセージを
<code>submit@bugs.debian.org</code> に送らないように注意してください。</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>Debian ポリシーに対して見すごせない違反がある(つまり、"must" や
"required" の要件に違反している)、またはパッケージメンテナの意見として
そのパッケージがリリースに適していないと判断された場合。

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

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

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

<dt><code>fixed(修正済)</code>
<dd>修正されているが、まだクローズしてはいけないバグ。
ノンメンテナ・アップロードによって修正されたバグとしての例外。
注意: 代わりに "fixed" <strong>タグ</strong>を使用うべき。
</dl>

<p>ある severity は
<em><a href="http://bugs.debian.org/release-critical/";>リリースクリティカル</a></em>,
つまりDebianの安定版のパッケージとしてリリースするには問題があるバグで
あることを意味しています。現在、<strong>critical</strong>と
<strong>grave</strong>, <strong>serious</strong>がそれに相当します。</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>potato</code>
  <dd>このバグは特に Debian の potato リリースに加えられるものです。

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

<dt><code>sid</code>
  <dd>このバグは、特に現在リリースされていないアーキテクチャ
  (つまり、sid ディストリビューションにあるもの) に加えられるものです。
</dl>

<p>最後の 3 つのタグは主にリリースクリティカルバグのために使われるものです。
バグの修正(やパッケージの削除)によって、どのディストリビューションが影響
するのかを明確にするためのものです。


<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> を入れること。</P>

<P>原作者が返信をする際に、<code>CC</code> に
<var>nnn</var><code>-forwarded@bugs</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="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="subjectscan">廃止されつつあるサブジェクト検査機能</a></h2>

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

<P><code>maintonly</code>、<code>done</code>、<code>quiet</code>、
<code>forwarded</code> についても同様に扱われます。これらのアドレスでは、
サブジェクトタグのあるメールは対応する 
<var>nnn-whatever</var><code>@bugs</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"