--- Begin Message ---
矢吹です。
翻訳していていました。とりあえず、明日から仕事なので
思ったほど進んでいませんし、「とほほ」な訳もおおいの
ですが、とりあえず一区切りつけるために、佐野さんに
渡しておきます。
$gProject $gBug 追跡システムのページ
$gProjectTitle ユーザや開発者によって報告された $gBugs の詳細を $gBug 追跡システムは持っています。それぞれの$gBugは、番号が与えられ、その問題が対処された状態になるまで、その状態を保持します。
$gBug追跡システムについての文書
・$gBug レポートの説明
・$gBug レポートログの閲覧方法
・emailによる $gBug レポートの要求方法
・開発者情報 どのように、このシステムを使うか
・開発者情報 emailによる $gBugs の操作方法
・メールサーバのリファレンスカード
WWW上での $gBug レポート閲覧
・全ての未解決問題および最近の $gBug レポート
・パッケージ毎の $gBug レポート
・メンテナー毎のパッケージの $gBug レポート
・未解決の「致命的」「重大」「通常」および「fixed(固定化?,どんな状態?)」の $gBug および 「要望」
・(upstreamへ)転送された「致命的」「重大」「通常」および「fixed」の $gBugs および 「要望」
・解決した「致命的」「重大」「通常」および「fixed」の $gBugs および 「要望」
・パッケージ毎にソートされた、未解決レポートの要約
・番号順にソートされた、未解決レポートの要約
・特定の $gBug レポートに関連しないログ
・タイムスタンプ(現在ミラーされているかのチェック)
$gBug レポートは、関係する最後のメッセージを受信してファイルされてから $gRemoveAge 日後に (レポートの保有期間が)切れて、クローズされます。以下のフォームからバグレポートを検索することができます。
$gBug レポートを見つける
番号で
パッケージで
()現在のバグ ()アーカイブにあるバグ
メンテナーのe-mailで
()現在のバグ ()アーカイブにあるバグ
報告者のe-mailで
()現在のバグ ()アーカイブにあるバグ
$gAccessHtml = < 本追跡システムログの $gBug レポートにアクセスする
これらのメッセージを受け取ったか、$gBug 処理システムが送信されたか、ログに記録して、(主語は?)は沢山の方法で利用可能になっています。
これらはメールサーバへ 必要に応じてプレーンテキストの $gBugレポートを送信します。これを使うには、email(メールの題名は無視されます)による一件の内容のhelp wordを送るか、bug-log-mailserver.txtという取り扱い説明書のWWWの読みます。
他のページ
・ $gBug 追跡システムのページへ
・ $gBugs へレポートを出すための説明
・ 開発者用情報 $gBug 処理システムへの考慮する点について
・ 未解決問題の全リストおよび最近の $gBug レポート
・ パッケージの $gBug レポート
・ メンテナーが持っているパッケージの $gBug レポート
どのように $gProjectへ $gBug を報告するか
以下の説明を見て、submit\@gEmailDomainへメールを送る。
関係ない、いくつかの $gBugs をレポートしないでください。- とくに一つメッセージに異るパッケージのレポートはしないでください。また、あなたの$gBugレポートをいかなるメーリングリストやsubmit\@$gEmailDomainを除く他の受信者にメールを送信しないでください。(どうすれば良いのかの詳細は以下を見よ)
現在の未解決 $gBugs のリストは、「Web」か「そのほか」で参照可能です。--詳細は他の文書を見よ
メッセージの本体の最初にパッケージ名はバージョン名と擬似ヘッダを置く必要があります。それらの行には、$gBugを報告するパッケージの名前やパッケージのバージョンがかかれます。(擬似ヘッダフィールドは、行頭から始まらねばなりません。$gBug システムは、今のところMIMEやPGPのメールを正しく理解しませんし、そのようなメールの中にある擬似ヘッダの認識に失敗するでしょう。
以下の「さらなる必要条件(further requirements)」を見よ。
例
メールのヘッダ付き $gBug レポートは、以下のように見える
To: submit\@$gEmailDomain
From: diligent\@testing.linux.org
Subject: Hello says `goodbye'
<A name="pseudoheader">Package: hello</a>
Version: 1.3-16
When I invoke `hello' without arguments from an ordinary shell
prompt it prints `goodbye', rather than the expected `hello, w
orld'.
Here is a transcript:
$ hello
goodbye
$ /usr/bin/hello
goodbye
$
I suggest that the output string, in hello.c, be corrected.
I am using Debian GNU/Linux 2.2, kernel 2.2.17-pre-patch-13
and libc6 2.1.3-10.
あなたのレポートに入れてほしいもの
・表示されるかログに記録された、いかなる種類のエラーメッセージの正確かつ全部の内容。これが大変重要なのです!
・正確に、どのように入力したか、または、そのプログラムをつかって実例してみてください。
・間違った振舞いの記述について:あなたの予期した振舞い、または何がおこったのかの観察を正確に記述してください。typescriptコマンドの実行してからのサンプルの実行結果は、これを示すのに良い方法です
・もし解決策をもっているいるなら、修正方法の示唆またはパッチ
・そのプログラムの詳細な設定。設定ファイルの全文を含みます。 $gXtraBugInfo
直接的に関係するように見える全ての詳細-、情報過多の長大なレポートを作ることはあなたにとってとても小さい負担です。もし、そのレポートが小さいなら、その問題を再現するのに使う全てのファイルを含めてください。(もし奇妙な文字を含んでいるようならuuencoudeを使って送ってください)
もちろん、どのようなEmailであっても 件名の部分には内容を説明したメールでなければなりません。この件名が、追跡システムの 最初の $gBugタイトルとしてつかわれます。この件名が有用であるようにしてください。
$gBug レポートの写しを他の(Email)アドレスへ送る
ときには、$gBug レポートの写しをメーリングリストやパッケージメンテナ以外送る必要があります。メーリングリストやパッケージメンテナには普通にメールを送信します。(which is where they are normally send ってどこにかかるのかよくわかりませんでした)
上記のことをするには、$gBugレポートを別のアドレス送信するのにCCを使います。すると、レポートのコピーには、Reply-Toフィールドと件名の部分に、$gBugレポート番号は付いていません。受信者が返答する時、ヘッダの中にあるsubmit\@$gEmailDomainへのエントリは多分保存されますが、新しい $gBug レポートとしてそれらのメッセージはファイルされます。これは、多数の複製されたレポートを作るようにしむけます。
正しい方法は、X-Debbugs-CCヘッダを使うことです。あなたのメールヘッダに以下のような行を追加します。(パッケージフィールドの擬似ヘッダないことに注意)
X-Debbugs-CC: other-list\@cosmic.edu
これにより $gBug 追跡システムは、あなたからのレポートを X-Debbugs-CC行にあるアドレスに加えてメーリングリストにも複製して送信します。
この特徴により、ひっそりとメールすることにより有用さが、しばしば増します。
(バグの)深刻度 (訳注：Serverity levelを重要度とか、訳しているのはあとで変更)
もし、レポートが著しく深刻な $gBug の場合、また、単に機能の要望に過ぎない場合、$gBug レポートに深刻度を設定することができます。これは必須ではありませんが、開発者はあなたが深刻度の設定をしなくても、あなたのレポートを適切な深刻度にするでしょう。
深刻度を設定するのは、Servertyヘッダを使います。深刻度の行は、擬似へッダにあり、パッケージの名前とバージョンと一緒に使います。深刻度は「開発者用文書」に記述されています。
メーリングリストへ転送しない - 軽度の $gBug レポート
もし $gBugレポートが軽度(例えば、文書の誤記やプログラムのビルドに関する些細な問題)であれば、一度に多数のバグレポートを maintonly\@gEmailDomainか、quiet\@$gEmailDomainに送ります。maintonlyは、パッケージのメンテナにレポートが送られます。(擬似ヘッダのパッケージ行に正しく指定されおり、メンテナが判明している場合)そしてquietは、どこかへも転送しないが、$gBugとしてファイルされる(これは以下のような場合に有用である、例えば、同様多数の $gBugsを登録して、要約だけを投稿したい場合)
もし この $gBug システムがいかなる転送メッセージにReply-Toを設定するのであれば、元のバグレポートと同じ方法で処理されるだろう(???)
よくわらからないパッケージへの $gBug レポート
もし $gBug 追跡システムが関連するパッケージのメンテナが登録されてないなら、例えmaintionlyを使ったとしてもレポートは、メーリングリストへ転送されます。
maintonly\@$gEmailDomainかnnn-maintonly\@$gEmailDomainにメールを送る時には、 $gBug レポートが正しいパッケージに割当てられていることを確認する必要があります。正しいパッケージが提出するレポートの最初におかれているか、もし正しくないなら、control\@$gEmailDomainサービスで、レポートの適切なパッケージへ(再)割当てします。
他のページ
・ $gBug 追跡システムのページへ
・ $gBugs へレポートを出すための説明
・ 開発者用情報 $gBug 処理システムへの考慮する点について
・ 未解決問題の全リストおよび最近の $gBug レポート
・ パッケージの $gBug レポート
・ メンテナーが持っているパッケージの $gBug レポート
最初に、$gBugレポートは、通常 submit\@EmailDomainによって登録される。これにより、番号が付加され、ユーザに応答が返り、(もし設定していたら)メーリングリストにも転送されます。もし、登録者が既知のメンテナのパッケージに登録されているパッケージを含んでいれば、メンテナもコピーを取得できるでしょう。
件名(Subject)の部分には、$gBug#nnn: が付加され、メールヘッダのReply-Toが登録者のレポートと nnn\@$gEmailDomain の両方に設定されます。
$gBug レポートを閉じる
開発者が追跡システムから $gBug を受け取る、または バグレポートをメーリングリストで見たなら、開発者は好みのメールリーダをつかって返答する責任がある。そして、(やりとりが)終ったら Toフィールドに nnn\@gEmailDomainの代りにnnn-done\@gEmailDomainとする。(nnn-closeは、nnn-doneのエイリアス(メールアドレス)として提供されています)
$gBugシステムが レポートの送信者アドレスをReply-Toヘッダに入れるため、$gBug レポートの送信者アドレスは、デフォルトで加えられます。
もし、メーリングリストが設定されている場合、「Done(完了)」メッセージは、自動的に $gDoneListメーリングリストに転送されます。
$gBugを閉じた人および、(バグレポートの)送信者に(バグ)レポートの状態が変化したことを通知を受けとります。
メッセージのフォローアップ
もし開発者が、$gBug レポートに返答することにしたら、返答のメッセージは簡単にしてください(返答は、bugを完了状態にしません)。(デフォルトの場合、で、Reply-To:ヘッダが尊重される場合)返答は、nnn\@$gEmailDomainと $gBug レポートの送信者に行きます。(注：これは全く異なる2つのアドレスです)。この $gBug 追跡システムは、nnn\@gEmailDomainからのメッセージを受けとると、そのメッセージを、そのパッケージのメンテナに送り、バグレポートの残りのログを返答とともにファイルして、意図したメーリングリストへ転送します。
開発者は明らかにバグの登録者へのメールを、nnn-submitter\@gEmailDomainとしてメールしてよい。
もし、あなたがいかなるメーリングリストへメールするのが適切でないメッセージを送るのを望むのであれば、そのメッセージをnnn-quiet\@gEmailDomainか、nnn-maintonly\@gEmailDomainへメールを送ることができます。nnn-quiet\@gEmailDomainへメールするのは、$gBug 追跡システムへファイルするが、いかなる個人やメーリングリストへも配送されません。nnn-maintonly\@$gEmailDomainにメールすることは、$gBug 追跡システムにファイルされ、質問したパッケージのメンテナだけに配送されます。
あなたが、受信者に価値のあるedit downするつもりでなければ、あなたのメーラの「全ての受信者に返信」や「フォローアップ」機能を使わないでください。特にフォローアップのメッセージをnnn\@$gEmailDomainとsubmit\@$gEmailDomainに送らないでください。なぜならば、$gBugシステムは2つの写しを受け取って、それぞれを設定したメーリングリストへ別々に転送するでしょう。
重要度(Serverity levels)
この $gBug システムは、 各々の $gBug レポートに 重要度を記録しています。デフォルトでは $gDefaultSerity が設定されていまが、$gBugが登録された時にServerity行という擬似ヘッダを入れることか( $gBugsレポートの説明 を見よ) 、コントロールリクエストサーバにServerityコマンドを使うことにより変更できます。
重要度レベルは
$gHTMLServerityDesc
$gBug レポートのタグ
それぞれの $gBug は、0 またはそれ以上のタグが付加されています。それらのタグは、パッケージのページを見た時の$gBugsのリストや、$gBugログの全文を見たときに表示されます。
タグは $gBugが登録された時の擬似ヘッダのTag行として設定されます。
現在の $gBug タグは、
$gHTMLTagDesc
記録する あなたが passed on した $gBugレポート
開発者が $gBug レポートを $gProject パッケージより分岐したソースパッケージであると送ってきたら、それらのパッケージに、$gBug追跡システムは以下のように注意せねばならない。
あなたのメッセージのTOフィールドが、author toが(author to というフィルードがあるのか? それとも「作者へ」か?)が作者へのアドレスか確認する。両方の人物に、$gBugレポートが送られ、nnn-forwarded\@gEmailDomainがCCフィルドにはいります。
nnn-forwarded\@$gEmailDomainへCCした作者との応答を保存したいなら、$gBug追跡システムは、元々のレポートへの返答をファイルします。
$gBug 追跡システムがnnn-forwardedのメッセージを受け取った時には、関係する $gBug が そのメッセージとともにTo フィールドに転送されたものとして扱います。
あなたは、メッセージをcontorl\@$gEmailDomainに送ることで「forwarded to」情報を、変更することができます。
(バグリスト)要約の投稿
毎週金曜日に、未処理の$gBugレポートの一覧を(もし設定していれば)要約メーリングリストに、レポートを年代順にソートして投稿します。毎週火曜日には、パッケージメンテナ毎にソートされた、投稿されてから長い間無応答の $gBug レポートを投稿します。
再オープン、再指定、$gBugsの操作
$gBugレポートを他のパッケージに再指定したり、誤って閉じてしまったのレポートを再オープンしたり、(saying to whereって?)情報を修正したりもしどこかで、$gBug レポートが送られており、重要度やレポートのタイトルが変更され、$gBugレポートのマージ(統合?)とアンマージ(分化?)することはすることは可能です。(なんか、わけわからん文ですね。むー)。これは、control\@$gEmailDomainにメールを送ることでおこなわれます。
これらのメッセージの形式は、WWWか、bug-maint-mailcontol.txtという別の文書で説明されています。プレーンテキストバージョンの文書も、上記のサーバのアドレスにhelpワードを送ることで取得できます。
もはや廃れてしまった件名スキャン機能
送信されたメッセージが到着するか、件名がBug#nnnで始まる $gBugs は nnn\
@$gEmailDomainへ送ったものとしてあつかう。これはメールが旧のアドレスに送られるのと、間違えて送ったフォロアップのメールをつかまえるという後方互換性の両方である(例えば、全ての受信者に返答するのを使うなど)
同様の図式として、maintonly,done,quitやforwardを操作するのに、件名タグのついたメールが届いたのなら、nnn-whatever\@$gEmailDomainアドレスに関係したメールが送られている。
メッセージが届いたら、単に転送して終了します。ie $gBugレポートがない番号の(メール)アドレス - また、件名の中に $gBug 番号のないものは、junkとしてファイルされ、数週間保持されますが、そうでないものは無視されます。
他のページ
・ $gBug 追跡システムのページへ
・ $gBugs へレポートを出すための説明
・ 開発者用情報 $gBug 処理システムへの考慮する点について
・ 未解決問題の全リストおよび最近の $gBug レポート
・ パッケージの $gBug レポート
・ メンテナーが持っているパッケージの $gBug レポート
--- End Message ---