- Merge the following from the English version:

r16288 -> r19282	head/ja_JP.eucJP/ja_JP.eucJP/articles/problem-reports/article.xml

Submitted by:	Hiroo Ono <hiroo _at_ jp dot FreeBSD dot org>
References:	[doc-jp-work 997, 1302]

ja_JP.eucJP/articles/problem-reports/article.xml

@@ -7,7 +7,7 @@
 
 <!--
    The FreeBSD Japanese Documentation Project
-   Original revision: 1.23
+   Original revision: r19282
    $FreeBSD$
 -->
 
@@ -15,6 +15,16 @@
   <articleinfo>
     <title>FreeBSD 障害報告の書き方</title>
 
+    <legalnotice id="trademarks" role="trademarks">
+      &tm-attrib.freebsd;
+      &tm-attrib.cvsup;
+      &tm-attrib.ibm;
+      &tm-attrib.intel;
+      &tm-attrib.sparc;
+      &tm-attrib.sun;
+      &tm-attrib.general;
+    </legalnotice>
+
     <abstract>
       <para>この記事では、明瞭な障害報告 (Problem Report: PR) を
 	FreeBSD プロジェクトに提出する方法を解説します。</para>
@@ -70,11 +80,11 @@
       それらすべてが障害報告に値するというわけではありません。
       もちろん、誰しもが完璧ではありませんので、
       実際はコマンドの構文を勘違いしていたり、
-      設定ファイルに書き間違いをしている場合などを
+      設定ファイルを書き間違えているのに、
       プログラムにバグを見つけた! と思い込んでしまうことがあるでしょう
       (とは言っても、それ自身、文書が適切に記述されていなかったり、
       アプリケーションのエラー処理が甘いことを暗示している可能性があります)。
-      それ以外にも、障害報告を提出することが正しい行動ではなく、
+      それ以外にも、障害報告を提出することが正しい行動では<emphasis>なく</emphasis>、
       あなたや開発者たちをただ
       不満にさせるためだけに作用してしまう場合があります
       (訳注: はっきりと把握していないことを報告すべきではありません。
@@ -152,7 +162,14 @@
 
     <itemizedlist>
       <listitem>
-	<para>FAQ を調べる。</para>
+	<para>FreeBSD の
+	  <ulink url="../../books/faq/index.html">よくある質問とその答え</ulink>
+	  (FAQ) 一覧。
+	  FAQ は、
+	  <ulink url="../../books/faq/hardware.html">ハードウェア互換性</ulink>、
+	  <ulink url="../../books/faq/applications.html">ユーザアプリケーション</ulink> や
+	  <ulink url="../../books/faq/kernelconfig.html">カーネルコンフィグレーション</ulink>
+	  といったことに関する広い範囲の質問に対して答を示そうとしています。</para>
       </listitem>
 
       <listitem>
@@ -181,9 +198,21 @@
       </listitem>
 
       <listitem>
-	<para>最後に、FreeBSD 障害報告データベースを調べる。
-	  あなたの問題が新しいものでなかったり不明瞭であれば、
-	  既に報告されている可能性がかなりあります。</para>
+	<para>次に、検索可能な
+	  <ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
+	  FreeBSD 障害報告データベース</ulink> (GNATS) があります。
+	  あなたの問題が新しいものでも不明瞭でもなければ、
+	  既に報告されている可能性がかなり高いです。</para>
+      </listitem>
+
+      <listitem>
+	<para>最後に、
+	  もしもあるバージョンから別のバージョンにアップグレードしようとしているのであれば
+	  (特に <literal>-current</literal> ブランチに上げようとしているなら)、
+	  システムの <filename>/usr/src/UPDATING</filename> ファイルの内容か、
+	  <ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING"></ulink>
+	  にある最新版をよく調べておきましょう。
+	  このファイルは多くの非常に重要な情報を含んでいます。</para>
       </listitem>
     </itemizedlist>
 
@@ -212,11 +241,143 @@
     <para>自分の問題が障害報告を行うに値すると結論を出し、
       そしてそれが FreeBSD の問題点であると判断したのですから、
       実際に障害報告を執筆する時です。
-      環境変数 <envar>VISUAL</envar>
-      (か、もし <envar>VISUAL</envar>
-      が設定されていなければ <envar>EDITOR</envar>)
-      が何らかの使える値に設定されているか確認して、
-      &man.send-pr.1; を実行します。</para>
+      障害報告を作成して送信するプログラムの仕組みに入る前に、
+      障害報告をもっとも効果的なものにするこつをいくつか紹介しましょう。</para>
+
+    <section>
+      <title>よい障害報告を書くこつ</title>
+
+      <itemizedlist>
+	<listitem>
+	  <para><emphasis><quote>Synopsis</quote>(概要)
+	    行を空のままにしないでください。</emphasis>
+	    障害報告は、世界中に配布されるメーリングリストに送られる
+	    (そこでは、<quote>Synopsis</quote> (概要) は
+	    <literal>Subject:</literal> 行に使われます) と共に、
+	    データベースにも入れられます。後でデータベースを synopsis (概要)
+	    で参照する人は、題がついていない障害報告は単に無視することでしょう。
+	    このデータベースに登録された障害報告は、
+	    誰かが閉じるまでは残っていることを忘れないでください。
+	    内容不明のものは大抵雑音に埋もれてしまいます。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>わかりにくい<quote>Synopsis</quote> (概要)
+	    行は避けましょう。</emphasis>
+	    あなたが提出した障害報告を読む人がどういう状況か分かっていると仮定すべきではありません。
+	    できるだけ詳しく書きましょう。
+	    たとえば、その問題はシステムのどの部分にあてはまるのでしょうか。
+	    インストール中にしか問題に当たらないのか、それとも稼働中に当たるのか。
+	    具体的な例でいうなら、<literal>Synopsis: portupgrade is broken</literal>
+	    (概要: portupgrade がおかしい) ではなく、
+	    次のように書いたらどれだけ伝わりやすいか考えてみてください。
+	    <literal>Synopsis: port sysutils/portupgrade coredumps on
+	    -current</literal> (概要: sysutils/portupgrade port が
+	    -current でコアダンプします)。(ports の場合は、
+	    <quote>Synopsis</quote> (概要) 行に分類と名前を入れると、
+	    とても助かります)。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>パッチがあるなら、そう書いてください。</emphasis>
+	    パッチがついている障害報告は、
+	    ついていないものよりも見てもらえる可能性が高いです。パッチをつける場合は、
+	    <quote>Synopsis</quote> (概要) 行の先頭に
+	    <literal>[patch]</literal> という文字列をいれて下さい。
+	    (この通り書かなければならないというわけではありませんが、
+	    慣習としてこの文字列が用いられています)。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>あなたがメンテナなら、そう書いてください。</emphasis>
+	    ソースコードの一部 (たとえば、ある port) をメンテナンスし
+	    ているなら、概要行の先頭に
+	    <literal>[maintainer update]</literal> という文字列をいれたり、
+	    障害報告の <quote>Class</quote> を
+	    <literal>maintainer-update</literal> にすることを検討してください。
+	    こうすれば、committer がその障害報告を扱う際に、
+	    いちいち確認する必要がありません。</para>
+	    <!-- この部分は、rev.1.29 の変更を先取りしている。 -->
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>具体的に書いてください。</emphasis>
+	    あなたが抱えている問題について多くの情報を出すほど、
+	    回答してもらえる可能性は高くなります。
+	    動かしているバージョンは何か
+	    (これを記載する場所があります。後述します)、
+	    どのアーキテクチャで動かしているのか、
+	    リリースの CDROM から入れたものか、
+	    それとも &man.cvsup.1; でメンテナンスしているシステムなのか
+	    (そうだとしたら、最後に更新したのはいつか)、
+	    カーネルの問題なら <literal>src/UPDATING</literal> は読んだのか
+	    (間違いなく聞かれます) といったことを盛り込むべきです。
+	    カーネルコンフィグレーションや、どの ports
+	    が利用できるのかということや、コアダンプをつける必要はありませんが
+	    (無条件でそれらを添付するのは、
+	    単にデータベースを一杯にするだけになりがちです)、
+	    要求されたら非公開か公開どちらかで出せるように準備しておきましょう。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>漠然と機能を要求するのはやめましょう。</emphasis>
+	    <quote>誰かこういうことするものを実装すべきだ</quote>
+	    という形の障害報告は、詳細な要望に比べて成果を得にくいものです。
+	    ソースコードは誰でも利用できるのですから、何か機能が欲しければ、
+	    それをいれる最善の手段は作業にとりかかることです。
+	    また上述したように、こういうことは多くの場合、
+	    障害報告データベースに登録するよりも
+	    <literal>freebsd-questions</literal> で議論した方がよいでしょう。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>誰かが既に似たような障害報告を提出していないか確認してください。</emphasis>
+	    これは、既に述べたことではありますが、ここで繰り返しておくに値するでしょう。
+	    Web ベースの検索エンジン
+	    <ulink url="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query"></ulink>
+	    で調べるのは 1, 2 分程度しかかかりません。
+	    (もちろん、誰もがときどきこれを忘れてしまうという罪を犯しています)。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>異論のある要望は出さないようにしましょう。</emphasis>
+	    あなたの障害報告がかつて論争になった分野に関するものであったら、
+	    パッチを提出するだけでなく、そのパッチが
+	    <quote>正当なものである</quote> 根拠も提出したほうがよいかもしれません。
+	    どの場合でも上述のように
+	    <ulink url="http://www.FreeBSD.org/search/search.html#mailinglists"></ulink>
+	    でメーリングリストのアーカイブを検索して備えるのはよいことでしょう。</para>
+	</listitem>
+
+	<listitem>
+	  <para><emphasis>礼儀正しくしましょう。</emphasis>
+	    あなたの障害報告について作業する人は、
+	    ほとんど全員がボランティアです。
+	    金銭的収入以外の動機から行なっていることを、
+	    やれと命令されるのは誰も好きではありません。
+	    オープンソースプロジェクトに関しては、
+	    これを常に念頭においておくとよいでしょう。</para>
+	</listitem>
+      </itemizedlist>
+    </section>
+
+    <section>
+      <title>始める前に</title>
+
+      <para>&man.send-pr.1; プログラムを動かす前に、環境変数
+        <envar>VISUAL</envar> (もし <envar>VISUAL</envar>
+	が設定されていなければ <envar>EDITOR</envar>)
+	が意味のあるものに設定されているか確認しましょう。</para>
+
+      <para>また、メール配送ソフトウェアが正常に動作することも確認してください。
+	&man.send-pr.1; は障害報告の提出と追跡にメールを利用します。
+	&man.send-pr.1; を動かすマシンからメールを送ることができないと、
+	あなたの障害報告は GNATS データベースに届きません。
+	FreeBSD におけるメールの設定の詳細については
+	FreeBSD ハンドブックの <quote>電子メール</quote> の章
+	<ulink url="http://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/mail.html"></ulink>
+	をご覧ください。</para>
+    </section>
 
     <section>
       <title>パッチやファイルを添付する</title>
@@ -236,23 +397,29 @@
 
       <para>パッチは context 形式か unified 形式の差分を &man.diff.1; の
 	<option>-c</option> か <option>-u</option> オプションを
-	使って作成してください。
+	使って作成してください (unified 形式の方が好まれます)。
 	パッチを添付する場合、
 	開発者があなたの報告を読んで簡単にパッチを適用できるように、
-	修正したファイルの正確な CVS のリビジョン番号が特定できるか
-	確認してください。</para>
+	修正したファイルの正確な CVS のリビジョン番号が特定できるか確認してください。
+	新しいコードはすべて CVS の CURRENT または 
+	HEAD ブランチにあててテストするべきなので、
+	それに対するパッチが望ましいです。適切か十分なテストが行なわれたら、
+	そのコードは STABLE ブランチにマージまたは移植されます。</para>
 
-      <para>一般的に、
-	障害報告の中に小さなパッチを含める分にはいいのですが、
-	記載される問題についての修正が大規模な場合や新しいコードの場合は
-	十分な査読を行なった後にコミットすべきであるため、
-	パッチを Web や FTP サーバに置き、その URL を障害報告に含めてください。
+      <para>パッチを添付するのではなく本文中に含める場合、
+	もっともありがちな問題は、
+	電子メールプログラムによってはタブをスペースに変更してしまい、
+	Makefile に含めるつもりだったものを台無しにしてしまうことです。</para>
+
+      <para>また、障害報告の中に小さなパッチを含めるのは
+	(とりわけ説明されている障害を修正する場合は) 大抵問題ないのですが、
+	大規模なパッチや新しいコードの場合は十分な査読を行なった後にコミットすべきであるため、
+	パッチを Web や FTP サーバに置き、その URL を障害報告に書いてください。
 	電子メールに含めたパッチはサイズが大きいと分割される傾向にあり
-	(とりわけ Gnats が処理に関わるときはそうです)、
-	肝心な部分が変にならないように注意をはらってください。
-	また、パッチに変更があった場合、
-	元の障害報告へのフォローアップとしてパッチ全体を再提出しなくとも
-	Web から該当部分のパッチを送信して変更することができます。</para>
+	(とりわけ GNATS が処理に関わるときはそうです)、
+	パッチが大きいほど興味をもった人がつなぎ直すのが面倒になります。
+	また、Web にパッチをおけば、
+	元の障害報告へのフォローアップとしてパッチ全体を再提出しなくとも変更することができます。</para>
 
       <para>また、障害報告かパッチ自体に明確に指定がなければ、
 	あなたが提出したパッチは修正した元のファイルと同じ条件の
@@ -262,10 +429,10 @@
     <section>
       <title>テンプレートに記入する</title>
 
-      <para>テンプレートは特定のフィールドから成り立っており、
-	あらかじめ書き込まれた部分がいくつかあります。そこには
-	フィールドの目的が何かを説明する解説や
-	そのフィールドに利用可能な値が書かれています。
+      <para>&man.send-pr.1; を動かすとテンプレートが表示されます。
+	テンプレートは特定の項目から成り立っており、
+	その一部にはあらかじめ埋められていたり、
+	その項目の目的の解説やそこに記入できる値の一覧が記載されていたりします。
 	コメントの部分は、自分で変更・削除しなくても、
 	自動的に削除されますので心配する必要はありません。</para>
 
@@ -302,7 +469,7 @@
 	<listitem>
 	  <para><emphasis>Originator (あなたの名前):</emphasis>
 	    これは普通、現在ログインしているユーザの
-	    GECOS フィールドを使って既に埋められています。
+	    <literal>gecos</literal> フィールドを使って既に埋められています。
 	    あなたの実際の名前を指定してください。
 	    お好みで、名前の後ろに電子メールアドレスを
 	    山括弧 (&lt; と &gt; のこと) で閉じて付けることができます。</para>
@@ -340,7 +507,13 @@
 
 	  <para>障害報告にパッチを添付する場合、概要の先頭に
 	    <literal>[PATCH]</literal> と書いてください。</para>
-	</listitem>
+	  <para>上述したように、障害報告にパッチが含まれているなら、
+	    概要の先頭に <literal>[patch]</literal> と書いて下さい。
+	    あなたがメンテナなら、
+	    <literal>[maintainer update]</literal> を追加したり、
+	    障害報告の <quote>Class</quote> を
+	    <literal>maintainer-update</literal> にすることを検討してください。</para>
+ 	</listitem>
 
 	<listitem>
 	  <para><emphasis>Severity (重要度):</emphasis>
@@ -378,6 +551,11 @@
 		Alpha プラットフォーム固有の問題。</para>
 	    </listitem>
 
+	    <listitem>
+	      <para><literal>amd64:</literal>
+		AMD64 プラットフォーム固有の問題。</para>
+ 	    </listitem>
+
 	    <listitem>
 	      <para><literal>bin:</literal>
 		基本システムに含まれるユーザランドプログラムに関する問題。</para>
@@ -401,7 +579,7 @@
 
 	    <listitem>
 	      <para><literal>i386:</literal>
-		i386 プラットフォーム固有の問題。</para>
+		&i386; プラットフォーム固有の問題。</para>
 	    </listitem>
 
 	    <listitem>
@@ -411,7 +589,7 @@
 
 	    <listitem>
 	      <para><literal>java:</literal>
-		Java&trade; に関する問題。</para>
+		&java; に関する問題。</para>
 	    </listitem>
 
 	    <listitem>
@@ -421,7 +599,8 @@
 
 	    <listitem>
 	      <para><literal>misc:</literal>
-		これらの分類に適合しないその他の分類。</para>
+		これらの分類に適合しないその他の分類
+		(なお、ここに分類されると見失われやすいです)。</para>
 	    </listitem>
 
 	    <listitem>
@@ -431,12 +610,12 @@
 
 	    <listitem>
 	      <para><literal>powerpc:</literal>
-		PowerPC プラットフォーム固有の問題。</para>
+		&powerpc; プラットフォーム固有の問題。</para>
 	    </listitem>
 
 	    <listitem>
 	      <para><literal>sparc64:</literal>
-		SPARC プラットフォーム固有の問題。</para>
+		&sparc64; プラットフォーム固有の問題。</para>
 	    </listitem>
 
 	    <listitem>