os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Merge the following from the English version:

Browse source 
r21372 -> r26086	head/ja_JP.eucJP/articles/problem-reports/article.xml

Submitted by:	Hiroo Ono <hiroo _at_ jp dot FreeBSD dot org>
References:	[doc-jp-work 1755, 1769]
This commit is contained in:
Ryusuke SUZUKI 2012-12-28 23:14:03 +00:00
parent 3e05aa6e44
commit ddb8727a68
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=40491
1 changed files with 75 additions and 21 deletions

96
ja_JP.eucJP/articles/problem-reports/article.xml
View file

@ -7,7 +7,7 @@
<!--
The FreeBSD Japanese Documentation Project
Original revision: r21372
Original revision: r26086
$FreeBSD$
-->
@ -125,15 +125,30 @@
(主に ports のことですが、BIND やさまざまな
GNU ユーティリティのような外部で維持されている、
システムの基礎を構成するソフトェアも含まれます)。</para>
<para>メンテナンスされていない ports (<makevar>MAINTAINER</makevar>
が <literal>ports@FreeBSD.org</literal> になっています)
では、この手の更新通知は興味を抱いた committer
が取り上げるかもしれませんし、あなたがその port
を更新するパッチを提出することが求められるかもしれません。
あらかじめパッチを提出すれば、port
がただちに更新される可能性が非常に高くなります。</para>
<para>port がメンテナンスされている場合は、
一次配布元から新たなバージョンがリリースされたことを通知する障害報告は
committer に余分な作業をさせるだけであまり役に立たないかもしれません。
また、メンテナは新しいバージョンが出たことをすでに知っている可能性が高いです。
もしかすると、開発者と一緒に作業していて、
退行したところがないかなどをテストしているところかもしれません。</para>
<para>いずれの場合も、<ulink
url="&url.books.porters-handbook;/port-upgrading.html">Port
作成者のためのハンドブック</ulink>
で説明されている手順がもっともよい結果をもたらします。</para>
</listitem>
</itemizedlist>
<para>もう一つ、もし、バグに遭遇したシステムがあまり新しくない場合、
システムを最新の状態にして、
最新のシステムでも問題が再現するか試した後に障害報告を提出することを真剣に考えるべきです。
既に修正されたバグに関する障害報告を受けとることほど開発者を悩ませるものはまずありません。</para>
<para>最後に、再現することができないバグは、めったに直すことができません。
<para>再現することができないバグは、めったに直すことができません。
もし、バグが一度だけ発生してそれが再現できないもので、
なおかつ他の人のシステムでも起こらないようであれば、
開発者がそれを再現できる可能性も、
@ -145,6 +160,9 @@
CPU が原因で起きていることが多いのです
(障害報告を提出する前には必ず、可能なら、
こうした原因を排除するよう努めるべきです)。</para>
<para>それから、問題が時宜を得たものか確認すべきです。
既に修正したバグに関する障害報告を受けとることほど開発者を悩ませるものはまずありません。</para>
</section>
<section id="pr-prep">
@ -163,19 +181,19 @@
<itemizedlist>
<listitem>
<para>&os; の
<ulink url="../../books/faq/index.html">よくある質問とその答え</ulink>
<ulink url="&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>
<ulink url="&url.books.faq;/books/faq/hardware.html">ハードウェア互換性</ulink>、
<ulink url="&url.books.faq;/books/faq/applications.html">ユーザアプリケーション</ulink> や
<ulink url="&url.books.faq;/books/faq/kernelconfig.html">カーネルコンフィグレーション</ulink>
といったことに関する広い範囲の質問に対して答を示そうとしています。</para>
</listitem>
<listitem>
<para>
<ulink
url="../../books/handbook/eresources.html#ERESOURCES-MAIL">
url="&url.books.handbook;/eresources.html#ERESOURCES-MAIL">
メーリングリスト</ulink>。
&mdash; メーリングリストを購読していなければ、
&os; のウェブサイトにある
@ -453,7 +471,7 @@
<section>
<title>始める前に</title>
<para>&man.send-pr.1; プログラムを動かす前に、環境変数
<para>&man.send-pr.1; プログラムを使うなら、環境変数
<envar>VISUAL</envar> (もし <envar>VISUAL</envar>
が設定されていなければ <envar>EDITOR</envar>)
が意味のあるものに設定されているか確認しましょう。</para>
@ -464,8 +482,28 @@
あなたの障害報告は GNATS データベースに届きません。
&os; におけるメールの設定の詳細については
&os; ハンドブックの <quote>電子メール</quote> の章
<ulink url="http://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/mail.html"></ulink>
<ulink url="&url.books.handbook;/mail.html"></ulink>
をご覧ください。</para>
<para>あなたが使っているメーラが GNATS
に送るメッセージに手を加えないことを確かめておいてください。
特に、メーラが自動で改行したり、タブをスペースに変更したり、
改行文字をエスケープしたりすると、
提出したパッチは使えないものになってしまいます。
もっとも、テキスト部については障害報告を web
で表示した時に読みやすいように、
70 文字前後で改行を入れることをお願いしています。</para>
<para>&man.send-pr.1; の代わりに
web ベースの障害報告提出を利用する場合も、同様の配慮が必要です。
カットアンドペースト操作はテキストをフォーマットするのに副作用がある場合があるので気をつけてください。
場合によっては、パッチが変更されずに届くように、&man.uuencode.1;
を使わなければならないかもしれません。</para>
<para>最後に、提出物が長くなってしまうなら、
提出時に問題が起きて失われてしまうことのないように、
オフラインで準備しておきましょう。
これは特に web フォームで問題になります。</para>
</section>
<section>
@ -501,6 +539,12 @@
電子メールプログラムによってはタブをスペースに変更してしまい、
Makefile に含めるつもりだったものを台無しにしてしまうことです。</para>
<para>パッチを
<command>Content-Transfer-Encoding: quoted-printable</command>
を利用した添付ファイルとして送らないようにしてください。
これは文字をエスケープしてしまい、
パッチ全体が使い物にならなくなります。</para>
<para>また、障害報告の中に小さなパッチを含めるのは
(とりわけ説明されている障害を修正する場合は) 大抵問題ないのですが、
大規模なパッチや新しいコードの場合は十分な査読を行なった後にコミットすべきであるため、
@ -509,7 +553,11 @@
(とりわけ GNATS が処理に関わるときはそうなります)、
パッチが大きいほど興味をもった人がつなぎ直すのが面倒になります。
また、Web にパッチをおけば、
元の障害報告へのフォローアップとしてパッチ全体を再提出しなくとも変更することができます。</para>
元の障害報告へのフォローアップとしてパッチ全体を再提出しなくても変更できます。
最後に、大きなパッチはデータベースのサイズをとにかく増やしてしまいます。
閉じられた障害報告は実際に消されることはなく、
保持されたまま <literal>closed</literal>
という印をつけられるだけだからです。</para>
<para>また、障害報告かパッチ自体に明確に指定がなければ、
あなたが提出したパッチは修正した元のファイルと同じ条件の
@ -639,7 +687,7 @@
<listitem>
<para><emphasis>Category (分類):</emphasis>
以下から一つを選んでください (
<filename>/usr/gnats/gnats-adm/categories</filename>
<ulink url="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/send-pr/categories"></ulink>
からもってきています)。</para>
<itemizedlist>
<listitem>
@ -691,7 +739,9 @@
<listitem>
<para><literal>java:</literal>
&java; に関する問題。</para>
&java; 仮想マシンに関する問題。
(&java; に依存しているだけの ports は
<literal>ports</literal> に分類すべきです)。</para>
</listitem>
<listitem>
@ -730,7 +780,12 @@
<para><literal>threads:</literal>
&os; のスレッド実装 (特に &os.current; 上のもの)
に関する問題。</para>
</listitem>
</listitem>
<listitem>
<para><literal>usb:</literal>
&os; の USB 実装に関する問題。</para>
</listitem>
<listitem>
<para><literal>www:</literal>
@ -878,8 +933,7 @@
<para>または、
バグ追跡システムがどの障害報告に加えればよいか判断できるように、
件名に追跡番号が含まれているか確かめて
<email>bug-followup@FreeBSD.org</email>
にメールを送るだけでも構いません。</para>
&a.bugfollowup; にメールを送るだけでも構いません。</para>
<note>
<para>追跡番号を <emphasis>含めない</emphasis> と、
@ -920,7 +974,7 @@
</listitem>
<listitem>
<para><ulink
url="../../../en_US.ISO8859-1/articles/pr-guidelines/article.html">
url="&url.articles.pr-guidelines.en;/article.html">
障害報告 取り扱いガイドライン</ulink> &mdash;
障害報告が &os; の開発者によってどのように扱われるかについて
有益な見識をまとめた記事。</para>