diff --git a/ja_JP.eucJP/articles/problem-reports/article.xml b/ja_JP.eucJP/articles/problem-reports/article.xml index d03c35488e..bee23888e3 100644 --- a/ja_JP.eucJP/articles/problem-reports/article.xml +++ b/ja_JP.eucJP/articles/problem-reports/article.xml @@ -3,7 +3,7 @@ "http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
サポートされているバージョンの一覧 を管理しています。 - ある port に問題がある場合、まずはじめに Ports Collection - の最新版にアップグレードして、 - まだ問題が起きるかどうかを確認してください。 - これらのアプリケーションは速いペースで変更されるため、 - &os; で完全な最新版以外に対応するのは不可能です。 - アプリケーションの古いバージョンにある問題は、 - 直しようがありません。 + ある port に問題がある場合、 + 開発元にバグを報告することを考えて見てください。 + すべてのソフトウェアのすべてのバグに対し、&os; + プロジェクトが修正することは不可能です。
@@ -328,7 +325,7 @@ Summary(概要) 行を空のままにしないでください。 障害報告は、世界中に配布されるメーリングリストに送られる - (そこでは、Synopsis (概要) は + (そこでは、Summary (概要) は Subject: 行に使われます) と共に、 データベースにも登録されます。後でデータベースを synopsis (概要) で参照する人は、 @@ -339,40 +336,35 @@ - わかりにくいSynopsis (概要) + わかりにくい Summary (概要) 行は避けましょう。 あなたが提出した障害報告を読む人がどういう状況か分かっていると仮定すべきではありません。 できるだけ詳しく書きましょう。 たとえば、その問題はシステムのどの部分にあてはまるのでしょうか。 インストール中にしか問題に当たらないのか、それとも稼働中に当たるのか。 具体的な例でいうなら、 - Synopsis: portupgrade is broken + Summary: portupgrade is broken (概要: portupgrade がおかしい) ではなく、 次のように書いたらどれだけ伝わりやすいか考えてみてください。 - Synopsis: port ports-mgmt/portupgrade coredumps on + Summary: port ports-mgmt/portupgrade coredumps on -current (概要: sysutils/portupgrade port が -current でコアダンプします)。(ports の場合は、 - Synopsis (概要) 行に分類と名前を入れると、 + Summary (概要) 行に分類と名前を入れると、 とても助かります)。 パッチがあるなら、そう書いてください。 パッチがついている障害報告は、 - ついていないものよりも見てもらえる可能性が高いです。パッチをつける場合は、 - Synopsis (概要) 行の先頭に - [patch] という文字列 (角括弧を含みます) - をいれて下さい。 - (この通り書かなければならないというわけではありませんが、 - 慣習としてこの文字列が用いられています)。 + ついていないものよりも見てもらえる可能性が高いです。 + Bugzilla の Keyword で patch + を選択してください。 あなたがメンテナなら、そう書いてください。 ソースコードの一部 (たとえば、ある port) - をメンテナンスしているなら、概要行の先頭に - [maintainer update] - という文字列 (角括弧を含みます) をできればいれて、障害報告の + をメンテナンスしているなら、障害報告の Class を必ず maintainer-update にしてください。こうすれば、committer @@ -550,7 +542,8 @@
始める前に - web + web ベースの障害報告提出フォーム を利用する場合も、同様の配慮が必要です。 カットアンドペーストを行う場合には、 @@ -565,10 +558,11 @@ パッチやファイルを添付する パッチを添付する場合、 - unified 形式の差分を &man.diff.1; の - オプションを使って作成してください。 + unified 形式の差分を svn diff または + &man.diff.1; の + オプションを使って作成してください。 開発者があなたの報告を読んで簡単にパッチを適用できるように、 - 修正したファイルの正確な + 修正したファイルに対するリポジトリの SVN のリビジョン番号が特定できることを確認してください。 カーネルやベースのユーティリティに関しては、新しいコードはすべて &os.current; (SVN の HEAD ブランチ) @@ -627,13 +621,6 @@ 概要は障害報告メールのサブジェクトとして利用されており、 一覧や要旨にも使われています。 概要が不明瞭な障害報告は無視される傾向があります。 - - 上述したように、障害報告にパッチが含まれているなら、 - 概要の先頭に [patch] (角括弧を含みます) - と書いて下さい。 - Ports に関する障害報告で、あなたがメンテナなら、 - [maintainer update] (角括弧を含みます) - を追加してください。 @@ -765,7 +752,7 @@ amd64 (この分類には、EMT64 モードで動作する Intel 互換のコンピュータも含まれます) を選択してください。 通常はあまりよく使われないアーキテクチャには、 - arm, ia64 および + arm および powerpc があります。 @@ -849,16 +836,11 @@ 最初の報告の中で言及しなかったものを思い出したり発見したら、 フォローアップを提出してください。 バグが修正されない一番の理由は、 - 提出者とのコミュニケーション不足が原因です。 - - - - 一番楽なのは、 - 障害報告検索ページ から行ける、それぞれの障害報告の - web ページのコメントオプションを利用することです。 - - + 提出者とのコミュニケーション不足が原因です。 + 一番楽なのは、 + 障害報告検索ページ から行ける、それぞれの障害報告の + web ページのコメントオプションを利用することです。 問題がなくなったのに障害報告の処理が完了していなければ、 できれば、どのように、いつ、問題を解決できたかの説明を添えて、