diff --git a/ja_JP.eucJP/articles/problem-reports/article.xml b/ja_JP.eucJP/articles/problem-reports/article.xml index 1f3d0530b8..ea44de7f89 100644 --- a/ja_JP.eucJP/articles/problem-reports/article.xml +++ b/ja_JP.eucJP/articles/problem-reports/article.xml @@ -48,13 +48,11 @@
はじめに - ソフトウェアの利用者が持っている - 多くのいらただしい経験のうちの一つは、 + ソフトウェアの利用者として経験するもっともいらただしいことの一つは、 それはバグじゃない、ひどい障害報告だ などのようなそっけなく理解の役に立たない説明によって、 障害報告があっさり片付けられてしまうことです。 - 同様に、ソフトウェア開発者が持っている - 多くのいらただしい経験のうちの一つは、 + 同様に、ソフトウェア開発者が経験するもっともいらだたしいことの一つは、 実際は障害報告ではない単なるサポート要求や 何が問題でどのように再現するかについての情報が 乏しいまたは欠落している障害報告が殺到することです。 @@ -63,21 +61,21 @@ 上手な障害報告とはどういうものでしょうか? そうですね、単刀直入に要点を言えば、 上手な障害報告とは、迅速に解析を進め処理を行うことができ、 - 一度に利用者と開発者がお互いに満足できるものです。 + 利用者と開発者がお互いに満足できるものです。 この記事では主として FreeBSD の障害報告に焦点を絞っていますが、 他のソフトウェアプロジェクトでも多くの部分が当てはまるでしょう。 この記事はテーマ別に整理されており、順番に読めるようにはなっていません。 - そのため、ステップバイステップのチュートリアルとして利用するよりも、 - 障害報告を提出する前に全体を通して読むとよいでしょう。 + そのため、段階を踏んだチュートリアルとして利用するのではなく、 + 障害報告を提出する前に全体を通して読むべきです。
いつ障害報告を提出すればよいのか - 問題には多くの種類がありますが、 - それらすべてが障害報告に値するというわけではありません。 + 問題にはさまざまな種類がありますが、 + それらすべてが障害報告に値するわけではありません。 もちろん、誰しもが完璧ではありませんので、 実際はコマンドの構文を勘違いしていたり、 設定ファイルを書き間違えているのに、 @@ -85,63 +83,61 @@ (とは言っても、それ自身、文書が適切に記述されていなかったり、 アプリケーションのエラー処理が甘いことを暗示している可能性があります)。 それ以外にも、障害報告を提出することが正しい行動ではなく、 - あなたや開発者たちをただ - 不満にさせるためだけに作用してしまう場合があります + あなたや開発者たちに不満を抱かせるだけという場合があります (訳注: はっきりと把握していないことを報告すべきではありません。 要領を得ない障害報告は扱いにくいものです)。 - 逆に、バグというよりも、 - 何か別の報告として提出した方が適切な場合があります — + 逆に、バグではありませんが障害報告を提出するのにふさわしい場合もあります + — たとえば、既存機能の拡張や新しい機能の搭載要求のようなものです。 では、何がバグで何がバグでないのか、 どのようにして決めれば良いでしょうか? - 簡単な経験則として、それを質問として (だいたい + 簡単な経験則では、それを質問として (よくあるのは どうすれば X できますか? や Y はどこで見つけることができますか? のような形式で) 表現できるなら、あなたの問題はバグではありません。 - いつも白黒はっきりするわけではありませんが、 - この質問規則は問題の非常に多くの部分があてはまります。 + いつも白黒がつけられるわけではありませんが、 + この質問規則は大半の場合にあてはまります。 もし、このような質問に対する答えを求めているのなら、 - &a.questions; にあなたの質問を送ってみることを検討してください。 + &a.questions; で質問してみてください。 訳注 &a.questions; へのメールは英語でお願いします。 - 日本語にでの質問は、&a.jp.users-jp; か - FreeBSD-beginners-jp@ux.mycom.co.jp + 日本語での質問は、&a.jp.users-jp; や + FreeBSD-beginners-jp メーリングリスト などに送ってください。 - バグではないものに関する障害報告を - 提出することが適切かもしれない条件は、以下のような時です。 + バグではないものに関する障害報告を提出することが適切と考えられるのは、 + 以下のような場合です。 機能拡張の要求。 - 障害報告を提出する前に、メーリングリストに - これらのことを表明することは一般的に良い考えです。 + 一般的には、障害報告を提出する前に、 + メーリングリストに要求を流すとよいでしょう。 外部で管理されているソフトウェアの更新通知 - (主に ports のことです。BIND やさまざまな GNU ユーティリティのような - システムの基礎を構成するソフトェアは外部的に管理されていますが、 - ここでは除きます)。 + (主に ports のことですが、BIND やさまざまな + GNU ユーティリティのような外部で維持されている、 + システムの基礎を構成するソフトェアも含まれます)。 - もう一つ、もし、バグに遭遇したシステムが実際には最新でない場合、 - システムを最新の状態にして、最新のシステムでも問題が再現するか試した後に - 障害報告を提出することを真剣に考えるべきだということです。 - 既に修正されたバグに関する障害報告を受けとること以上に、 - 開発者を悩ませるものはほとんどありません。 + もう一つ、もし、バグに遭遇したシステムがあまり新しくない場合、 + システムを最新の状態にして、 + 最新のシステムでも問題が再現するか試した後に障害報告を提出することを真剣に考えるべきです。 + 既に修正されたバグに関する障害報告を受けとることほど開発者を悩ませるものはまずありません。 最後に、再現することができないバグは、めったに直すことができません。 もし、バグが一度だけ発生してそれが再現できないもので、 なおかつ他の人のシステムでも起こらないようであれば、 - 開発者はそれを再現しようとしてもできませんし、 - 何が悪いのか理解する機会もありません。 + 開発者がそれを再現できる可能性も、 + 何が悪いのかわかる可能性もありません。 これはバグが起こらなかったことを意味するわけではありません。 しかし、このような状況ではあなたの障害報告がバグの修正に つながる見込みは非常に薄く、報告をやめることを検討すべきです。 @@ -150,15 +146,15 @@
準備 - 従うべき良い規則として、 + 従うべき良い規則は、 障害報告を提出する前に常に問題の背景を調べることです。 - おそらく、あなたの問題は既に報告されています。 - また、メーリングリストで議論されていたり、 - 最近議論されていたことでしょう。 - さらに、あなたが動かしているものより、 - 既に修正された新しいバージョンがあるかもしれません。 - したがって、障害報告を提出する前に明白な部分をすべて確認すべきです。 - FreeBSD では、以下のような方法があります。 + あなたの問題はすでに報告されているかもしれません。 + また、メーリングリストで議論されている最中か、 + 最近議論されていたかもしれません。 + あなたが動かしているものより新しいバージョンで、 + 既に修正済みということすらありえます。 + ですから、障害報告を提出する前に自明な場をすべて確認すべきです。 + FreeBSD については、以下のところになります。 @@ -176,7 +172,7 @@ - メーリングリストを利用する。 + メーリングリスト。 — メーリングリストを購読していなければ、 FreeBSD のウェブサイトにある ウェブ全体を検索する (任意)。— あなたの問題に関係する話題がないか - あなたのお気に入りの検索エンジンを使って探します。 - アーカイブされたメーリングリストやニュースグループを - 隅々まで検索すれば、知らなかったまたは思いもつかなかった結果を - 得ることができるかもしれません。 + あなたのお気に入りの検索エンジンを使って探してください。 + あなたが知りもしなかったか、 + 検索しようと考えなかったメーリングリストやニュースグループのアーカイブにあたることもあるかもしれません。 @@ -212,21 +207,21 @@ システムの /usr/src/UPDATING ファイルの内容か、 にある最新版をよく調べておきましょう。 - このファイルは多くの非常に重要な情報を含んでいます。 + このファイルは非常に重要な情報を多く含んでいます。 次に、障害報告が適切な人物に届くことを確認する必要があります。 まず、問題がサードパーティソフトウェアのバグであれば、 - 原作者に報告をすべきです。 + 原作者に報告すべきです。 そうでなければ、FreeBSD プロジェクトに報告してください。 このルールには二つの例外があります。 - 一つ目は、もしバグが他のプラットフォームで発生しなければ、 - FreeBSD に移植されたソフトウェアに原因が存在する場合です。 - 二つ目は、原作者がバグを既に修正していて - そのソフトウェアの新しいバージョンかパッチを公開しているが、 - FreeBSD に移植されたソフトウェアがまだ更新されていない場合です。 + 一つ目は、バグが他のプラットフォームで発生しない場合です。 + この場合は、FreeBSD への移植に原因がある可能性があります。 + 二つ目は、原作者がバグを既に修正していて、 + そのソフトウェアの新しいバージョンかパッチを公開しているのに、 + FreeBSD の port がまだ更新されていない場合です。 それから、FreeBSD のバグ追跡システムは 発信者が選択した分類に従って @@ -238,8 +233,8 @@
障害報告の書き方 - 自分の問題が障害報告を行うに値すると結論を出し、 - そしてそれが FreeBSD の問題点であると判断したのですから、 + 問題が障害報告を行うに値すると結論を出し、 + そしてそれが FreeBSD の問題点であると判断したら、 実際に障害報告を執筆する時です。 障害報告を作成して送信するプログラムの仕組みに入る前に、 障害報告をもっとも効果的なものにするこつをいくつか紹介しましょう。 @@ -257,7 +252,7 @@ データベースにも入れられます。後でデータベースを synopsis (概要) で参照する人は、題がついていない障害報告は単に無視することでしょう。 このデータベースに登録された障害報告は、 - 誰かが閉じるまでは残っていることを忘れないでください。 + 誰かが対応済にするまでは残っていることを忘れないでください。 内容不明のものは大抵雑音に埋もれてしまいます。 @@ -384,16 +379,16 @@ &man.send-pr.1; プログラムは、 障害報告にファイルを添付する機能を備えています。 - あなたが望む数だけ、それぞれ一意の名前を持ったファイル - (すなわち、パスを除いた適切な名前のファイル) - を添付することができます。 + それぞれのファイルの基本名称 + (すなわち、パスを除いたファイルそのものの名前) + が一意でありさえすれば、好きなだけ添付できます。 コマンドラインオプション で 添付するファイルの名前を指定してください。 &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors 添付するファイルがバイナリであっても心配しないでください。 - メールエージェントが混乱しないように、自動的に符合化が行われます。 + メールエージェントが混乱しないように、自動的に符合化されます。 パッチは context 形式か unified 形式の差分を &man.diff.1; の か オプションを @@ -414,9 +409,9 @@ また、障害報告の中に小さなパッチを含めるのは (とりわけ説明されている障害を修正する場合は) 大抵問題ないのですが、 大規模なパッチや新しいコードの場合は十分な査読を行なった後にコミットすべきであるため、 - パッチを Web や FTP サーバに置き、その URL を障害報告に書いてください。 + パッチを Web や FTP サーバに置き、その URL を障害報告に書くようにしてください。 電子メールに含めたパッチはサイズが大きいと分割される傾向にあり - (とりわけ GNATS が処理に関わるときはそうです)、 + (とりわけ GNATS が処理に関わるときはそうなります)、 パッチが大きいほど興味をもった人がつなぎ直すのが面倒になります。 また、Web にパッチをおけば、 元の障害報告へのフォローアップとしてパッチ全体を再提出しなくとも変更することができます。 @@ -440,7 +435,7 @@ と書かれている行の下が電子メールのヘッダです。 通常、この部分を変更する必要はありませんが、 障害報告を送信する機械やアカウントで - メールを出すことはできるが受けとることができない場合、 + メールを出すことはできても受けとることはできない場合、 From: と Reply-To: に 実際のメールアドレスを設定すべきです。 また、自分 (や他の誰か) に障害報告の複製を送りたい場合は、 @@ -455,7 +450,7 @@ フィールドの意味が分かり易いように フィールド名を訳していますが、 フィールドの値も含めて - 実際のフィールド名は英文字である必要があります。 + 実際のフィールド名は英文字でなければなりません。 @@ -485,14 +480,14 @@ Organization (所属組織): - あなたが望むのなら好きに使えます。 - このフィールドは何らかの深い意味で使われることはありません。 + あなたの好きなようにしてください。 + このフィールドは何らかの深い意味で使われることはありません。 Confidential (機密): これは no で既に埋められています。 - 機密扱いの FreeBSD 障害報告のようなものはないため、 + 機密扱いの FreeBSD 障害報告というものはないため、 変更することに意味はありません。— 障害報告データベースは CVSup によって、 世界的に配布されています。 @@ -505,14 +500,13 @@ 一覧や要旨にも使われています。 概要が不明瞭な障害報告は無視される傾向があります。 - 障害報告にパッチを添付する場合、概要の先頭に - [PATCH] と書いてください。 上述したように、障害報告にパッチが含まれているなら、 概要の先頭に [patch] と書いて下さい。 あなたがメンテナなら、 [maintainer update] を追加したり、 障害報告の Class を - maintainer-update にすることを検討してください。 + maintainer-update + にするようにしてください。 @@ -534,7 +528,7 @@ low (低い)、 medium (中間)、 high (高い) のどれかです。 - 分類の基準は前述されてますので読んでください。 + 分類の基準は前述していますので、読んでください。 @@ -543,7 +537,8 @@ advocacy: - FreeBSD の一般像に関する問題。めったに使われません。 + FreeBSD の世間的なイメージに関する問題。 + めったに使われません。 @@ -656,7 +651,7 @@ maintainer-update: - 保守者の ports に対する更新。 + あなたが保守している ports の更新。 @@ -665,8 +660,8 @@ Release: あなたが動作させている FreeBSD のバージョン。 これは &man.send-pr.1; によって自動的に書き込まれますが、 - もし、あなたが障害が起きているものと違うシステムから障害報告を - 送信する場合に限り変更する必要があります。 + あなたが障害が起きているものと違うシステムから障害報告を送信する場合に限り、 + 変更する必要があります。 @@ -681,8 +676,8 @@ そしてシステムの設定などのような関係する項目、 問題に影響を及ぼすインストールしたその他の ソフトウェアなどが含まれます。— - その問題が生じる環境を再構築するために、 - 開発者はなんでも知る必要があります。 + 手短にいうなら、その問題が生じる環境を再構築するために、 + 開発者が知らなければならないことすべてです。 @@ -712,13 +707,14 @@
障害報告を送信する - テンプレートを書き終えて、 - 保存してエディタを終了すると、&man.send-pr.1; は - s)end, e)dit or a)bort? のような - 表示を出して指示を求めます。 + テンプレートを埋め、保存してエディタを終了すると、 + &man.send-pr.1; は + s)end, e)dit or a)bort? + と表示して指示を求めます。 s を押せば障害報告の提出に進めますし、 - e だとエディタが再び実行されてさらに編集できます。 - a なら作業を中止できます。 + e だとエディタが再び実行され、 + ひきつづき編集できます。 + a なら作業を中止します。 abort を選択した場合、いままで書いていた障害報告はディスクに残りますので (&man.send-pr.1; は終了前にそのファイル名を示します)、 暇な時にそれを編集したり、場合によっては @@ -764,8 +760,8 @@
さらなる読みもの - 適切な障害報告の書き方と手順について関連する資料を示しますが、 - 決して完全なものではありません。 + 完全なものとはいえませんが、 + 適切な障害報告の書き方と手順について関連する資料を示します。