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

- Merge the following from the English version:

Browse source 
r45143 -> r47367	head/ja_JP.eucJP/articles/problem-reports/article.xml
This commit is contained in:
Ryusuke SUZUKI 2015-10-13 09:04:43 +00:00
parent 48fffd4f2b
commit 82fc9fc282
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=47545
1 changed files with 46 additions and 206 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -3,7 +3,7 @@
"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">
<!--
The FreeBSD Japanese Documentation Project
Original revision: r45143
Original revision: r47367
$FreeBSD$
-->
<article xmlns="http://docbook.org/ns/docbook"
@ -118,35 +118,36 @@
などに送ってください。</para>
</note>
<para>バグではないものに関する障害報告を提出することが適切と考えられるのは、
以下のような場合です。</para>
<para>ports または &os;
の一部ではない他のソフトウェアに関する障害報告を提出する際には、
以下に注意してください。</para>
<itemizedlist>
<listitem>
<para>外部で管理されているソフトウェア
(ports や contrib/ ディレクトリにあるソフトウェア)
の更新通知。</para>
<para>あるアプリケーションの新しいバージョンが利用可能という情報を知らせるだけの障害報告は提出しないでください。
ports のメンテナは、新しいバージョンが利用になった際には、
自動的に <application>portscout</application>
から連絡を受けています。
port を最新版へアップデートするためのパッチの提出は、
もちろん歓迎されます。</para>
</listitem>
<listitem>
<para>メンテナンスされていない ports (<varname>MAINTAINER</varname>
が <literal>ports@FreeBSD.org</literal> になっています)
では、この手の更新通知は興味を抱いた committer
が取り上げるかもしれませんし、あなたがその port
を更新するパッチを提出することが求められるかもしれません。
あらかじめパッチを提出すれば、port
がただちに更新される可能性が非常に高くなります。</para>
<para>port がメンテナンスされている場合は、
一次配布元から新たなバージョンがリリースされたことを通知する障害報告は
committer に余分な作業をさせるだけであまり役に立たないかもしれません。
また、メンテナは新しいバージョンが出たことをすでに知っている可能性が高いです。
もしかすると、開発者と一緒に作業していて、
退行したところがないかなどをテストしているところかもしれません。</para>
が <literal>ports@FreeBSD.org</literal> の ports)
に対する障害報告において、
パッチが添付されていないは、コミッタから取り上げられにくいです。
メンテナンスされていない port のメンテナになるには、
リクエストの障害報告を提出してください
(パッチがあることは好ましいですが、必須ではありません)。</para>
</listitem>
<listitem>
<para>いずれの場合も、<link
xlink:href="&url.books.porters-handbook;/port-upgrading.html">Port
作成者のためのハンドブック</link>
で説明されている手順がもっともよい結果をもたらします (<link
xlink:href="&url.articles.contributing-ports;/article.html">Contributing
xlink:href="&url.articles.contributing;/ports-contributing.html">Contributing
to the FreeBSD Ports Collection</link>
という文書も読んでみたいと思われるかもしれませんね)。</para>
</listitem>
@ -548,65 +549,23 @@
<section xml:id="pr-writing-before-beginning">
<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 データベースに届きません。
&os; におけるメールの設定の詳細については
&os; ハンドブックの <quote>電子メール</quote> の章 <uri
xlink:href="&url.books.handbook;/mail.html">&url.books.handbook;/mail.html</uri>
をご覧ください。</para>
<para>使用しているメーラが GNATS
に送るメッセージに手を加えないことを確かめておいてください。
特に、メーラが自動で改行したり、タブをスペースに変更したり、
改行文字をエスケープしたりすると、
提出したパッチは使えないものになってしまいます。
もっとも、テキスト部については障害報告を web
で表示した時に読みやすいように、
70 文字前後で改行を入れることをお願いしています。</para>
<para><link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi"> web
ベースの障害報告提出フォーム</link>
を利用する場合も、同様の配慮が必要です。
カットアンドペースト操作はテキストをフォーマットするのに副作用がある場合があるので気をつけてください。
場合によっては、パッチが変更されずに届くように、&man.uuencode.1;
を使わなければならないかもしれません。</para>
カットアンドペーストを行う場合には、
ホワイトスペースやその他のテキストフォーマットを変えてしまう可能性があるので、気をつけてください。</para>
<para>最後に、提出物が長くなってしまうなら、
提出時に問題が起きて失われてしまうことのないように、
オフラインで準備しておきましょう。これは特に
<link xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">web
フォーム</link> で問題になります。</para>
オフラインで準備しておきましょう。</para>
</section>
<section xml:id="pr-writing-attaching-patches">
<title>パッチやファイルを添付する</title>
<para>以下は、障害報告を電子メールで提出する場合にあてはまります。</para>
<para>&man.send-pr.1; プログラムは、
障害報告にファイルを添付する機能を備えています。
それぞれのファイルの基本名称
(すなわち、パスを除いたファイルそのものの名前)
が一意でありさえすれば、好きなだけ添付できます。
コマンドラインオプション <option>-a</option>
で添付するファイルの名前を指定してください。</para>
<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>
<para>添付するファイルがバイナリであっても心配しないでください。
メールエージェントが混乱しないように、自動的に符合化されます。</para>
<para>パッチを添付する場合、
パッチは context 形式か unified 形式の差分を &man.diff.1; の
<option>-c</option> か <option>-u</option>
オプションを使って作成してください (unified 形式の方が好まれます)。
unified 形式の差分を &man.diff.1; の
<option>-u</option> オプションを使って作成してください。
開発者があなたの報告を読んで簡単にパッチを適用できるように、
修正したファイルの正確な
SVN のリビジョン番号が特定できるか確認してください。
@ -633,15 +592,13 @@
大規模なパッチや新しいコードの場合は十分な査読を行なった後にコミットすべきであるため、
パッチを Web や FTP サーバに置き、
その URL を障害報告に書くようにしてください。
電子メールに含めたパッチはサイズが大きいと分割される傾向にあり
(とりわけ GNATS が処理に関わるときはそうなります)、
電子メールに含めたパッチはサイズが大きいと分割される傾向にあり、
パッチが大きいほど興味をもった人がつなぎ直すのが面倒になります。
また、Web にパッチをおけば、
元の障害報告へのフォローアップとしてパッチ全体を再提出しなくても変更できます。
最後に、大きなパッチはデータベースのサイズをとにかく増やしてしまいます。
閉じられた障害報告は実際に消されることはなく、
保持されたまま <literal>closed</literal>
という印をつけられるだけだからです。</para>
完了の状態で保持されたままになるだけだからです。</para>
<para>また、障害報告かパッチ自体に明確に指定がなければ、
あなたが提出したパッチは修正した元のファイルと同じ条件の
@ -651,26 +608,6 @@
<section xml:id="pr-writing-filling-template">
<title>テンプレートに記入する</title>
<para>次の節は電子メール方式にのみあてはまります。</para>
<para>&man.send-pr.1; を動かすと、テンプレートが表示されます。
テンプレートは特定の項目から成り立っており、
その一部にはあらかじめ埋められていたり、
その項目の目的の解説やそこに記入できる値の一覧が記載されていたりします。
コメントの部分は、自分で変更・削除しなくても、
自動的に削除されますので心配する必要はありません。</para>
<para>テンプレートの先頭にある <literal>SEND-PR:</literal>
と書かれている行の下が電子メールのヘッダです。
通常、この部分を変更する必要はありませんが、
障害報告を送信する機械やアカウントで
メールを出すことはできても受けとることはできない場合、
<literal>From:</literal> と <literal>Reply-To:</literal>
に実際のメールアドレスを設定すべきです。
また、自分 (や他の誰か) に障害報告の複製を送りたい場合は、
電子メールアドレスを
<literal>Cc:</literal> ヘッダに追加してください。</para>
<para>電子メールの雛型には、次の
2 つの一行フィールドがあります。</para>
@ -780,31 +717,12 @@
&os; 開発者がその問題に早くとりかかるわけではありません。
&mdash; 実際、
それが理由でこのフィールドにほとんど注意を払わない開発者もいます。</para>
<note>
<para>GNATS の情報はすべて公開されているので、
重要なセキュリティ上の問題は GNATS
に提出するべきでは<emphasis>ありません</emphasis>。
そのような問題は、<link
xlink:href="http://www.FreeBSD.org/ja/security/#how">セキュリティレポートガイドライン</link>
にしたがって送ってください。</para>
</note>
</listitem>
<listitem>
<para><emphasis>Priority (優先順位):</emphasis>
<literal>low (低い)</literal>、
<literal>medium (中間)</literal>、
<literal>high (高い)</literal> のどれかです。
<literal>high (高い)</literal>
は実質的にすべての &os; ユーザに影響するもの、
<literal>medium (中間)</literal>
は多くのユーザに影響するものに限定すべきです。</para>
<note>
<para>このフィールドはあまりにも乱用されたため、
いまやほとんど意味がなくなってしまいました。</para>
</note>
このフィールドには、
このバグがどの範囲に影響をおよぼしうるかを示します。</para>
</listitem>
<listitem>
@ -1119,9 +1037,7 @@
<listitem>
<para><emphasis>Release:</emphasis>
あなたが動作させている &os; のバージョン。
これは &man.send-pr.1; を使うと自動的に書き込まれますが、
あなたが障害が起きているものと違うシステムから障害報告を送信する場合に限り、
変更する必要があります。</para>
この項目は入力する必要があります。</para>
</listitem>
</itemizedlist>
@ -1167,29 +1083,6 @@
<section xml:id="pr-writing-sending">
<title>障害報告を送信する</title>
<para>&man.send-pr.1; を使っている場合</para>
<para>テンプレートを埋め、保存してエディタを終了すると、
&man.send-pr.1; は
<prompt>s)end, e)dit or a)bort?</prompt>
と表示して指示を求めます。
<userinput>s</userinput> を押せば障害報告の提出に進めますし、
<userinput>e</userinput> だとエディタが再び実行され、
ひきつづき編集できます。
<userinput>a</userinput> なら作業を中止します。
abort を選択した場合、いままで書いていた障害報告はディスクに残りますので
(&man.send-pr.1; は終了前にそのファイル名を示します)、
暇な時にそれを編集したり、場合によっては
よりネットワーク接続性のよいシステムに持っていくことができるでしょう。
この作業ファイルは、&man.send-pr.1; の
<option>-f</option> オプションを使って送ることができます。</para>
<screen>&prompt.user; <userinput>send-pr -f ~/my-problem-report</userinput></screen>
<para>上記の操作では、指定されたファイルを読み込み、
書式が正しいか検証し、ファイル中のコメント部分を取り除いて、
障害報告が送信されます。</para>
<para><link
xlink:href="https://bugs.freebsd.org/bugzilla/enter_bug.cgi">web フォーム</link>
を使っている場合</para>
@ -1210,8 +1103,8 @@
あなたの報告は拒否されてしまい、
書いたものを失ってしまうでしょう。</para>
<para>何らかの理由で画像が見られず、また &man.send-pr.1;
も使えない場合は、ご迷惑をおかけして大変申し訳ありませんが、
<para>何らかの理由で画像が見えない場合は、
ご迷惑をおかけして大変申し訳ありませんが、
障害報告を bugbuster チームに
<email>freebsd-bugbusters@FreeBSD.org</email>
宛で送ってください。</para>
@ -1233,48 +1126,23 @@
<para>誰かがあなたに追加情報を求めたり、
最初の報告の中で言及しなかったものを思い出したり発見したら、
次の 2 つの方法のどちらかで、フォローアップを提出してください。</para>
フォローアップを提出してください。
バグが修正されない一番の理由は、
提出者とのコミュニケーション不足が原因です。</para>
<itemizedlist>
<listitem>
<para>一番楽なのは、<link
xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">
障害報告検索ページ</link> から行ける、それぞれの障害報告の
web ページのフォローアップリンクを利用することです。
このリンクをクリックすると、
(ブラウザがそうするように設定されていれば)
正しい To: および Subject:
行を埋めた電子メール画面が表示されます。</para>
</listitem>
<listitem>
<para>または、
バグ追跡システムがどの障害報告に加えればよいか判断できるように、
件名に追跡番号が含まれているか確かめて
&a.bugfollowup; にメールを送るだけでも構いません。</para>
<note>
<para>追跡番号を <emphasis>含めない</emphasis> と、
GNATS は混乱して、新規に障害報告を生成して、それを
GNATS 管理者に割り当てます。
そうなると、誰かがゴミを片付けにくるまで、
何日または何週間も見失われたままになります。</para>
<para>間違ったやり方</para>
<programlisting>Subject: that PR I sent</programlisting>
<para>正しいやり方</para>
<programlisting>Subject: Re: ports/12345: compilation problem with foo/bar</programlisting>
</note>
web ページのコメントオプションを利用することです。</para>
</listitem>
</itemizedlist>
<para>問題がなくなったのに障害報告の処理が完了していなければ、
できれば、どのように、いつ、問題を解決できたかの説明を添えて、
この障害報告は議論を終了することができます、と
(前述の方法で) フォローアップを送ってください。</para>
この障害報告は議論を終了することができます、
とコメントを送ってください。</para>
<para>時々、提出した障害報告が誰にも割り当てられなかったり、
コメントのない状態が 1, 2 週間続くことがあります。
@ -1332,40 +1200,12 @@
<section xml:id="pr-problems">
<title>問題が起きたら</title>
<para>ほとんどの障害報告はシステムで処理され、
ただちに受け付けられます。しかし、GNATS の処理が遅れて、
10 分以上確認の電子メールが届かないこともあります。
しばらくお待ちください。</para>
<para>さらに、GNATS は入力をすべて電子メールで受け取るので、
&os; が渡されたメールをすべて spam フィルタに通しても影響が出ます。
1, 2 時間で返答を受け取っていなければ、
spam フィルタに引っかかった可能性があります。
その場合は、<email>bugmeister@FreeBSD.org</email>
にメールを送って GNATS 管理者の助力をもとめてください。</para>
<note>
<para>spam の判断基準に、(障害報告に HTML
をいれる必要はないにもかかわらず) spam によくみられる
HTML メールであるかどうか見るというものがあります。
障害報告を送る際には、HTML メールにしないことを強く推奨します。
フィルタにひっかかる可能性が高いだけでなく、
データベースをごちゃごちゃにしてしまうだけという可能性が高いからです。
昔ながらのテキストメールの方がずっとよいでしょう。</para>
</note>
<para>まれに、障害報告が受け付けられ、追跡番号が付いたのに、
web の検索ページのどの一覧にも表示されないことがあります。
その場合、おそらくデータベースの索引がデータベースそのものと
同期が外れてしまったのだと思われます。
本当にそうか確認する方法は、
<link xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">特定の障害報告を見る</link>ページにいって、
障害報告が出てくるか確認することです。
障害報告が存在するなら、<email>bugmeister@FreeBSD.org</email>
にメールを出して GNATS 管理者に知らせてください。
ただし、定期的にデータベースを再構築する <literal>cron</literal>
ジョブが走っていますので、急いでいるのでなければ、
特になにもする必要はありません。</para>
<para>バグシステムに関する問題を見つけたら、
バグとして提出してください。
まさにこの目的のためのカテゴリが用意されています。
もし障害報告の提出が難しいようであれば、バグマイスター
(<email>bugmeister@FreeBSD.org</email>)
に連絡をしてください。</para>
</section>
<section xml:id="pr-further">