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

- Merge the following from the English version:

Browse source 
r39654 -> r44225	head/ja_JP.eucJP/articles/problem-reports/article.xml
This commit is contained in:
Ryusuke SUZUKI 2015-09-05 04:24:43 +00:00
parent 470a2ec6ba
commit 76bd23420e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=47370
1 changed files with 31 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

61
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: r39654
Original revision: r44225
$FreeBSD$
-->
<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="ja">
@ -58,8 +58,9 @@
<para>この記事では主として &os; の障害報告に焦点を絞っていますが、
他のソフトウェアプロジェクトでも多くの部分が当てはまるでしょう。</para>
<para>この記事はテーマ別に整理されており、順番に読めるようにはなっていません。
そのため、段階を踏んだチュートリアルとして利用するのではなく、
<para>この記事はテーマ別に整理されており、
順番に読めるようにはなっていません。
段階を踏んだチュートリアルとして利用するのではなく、
障害報告を提出する前に全体を通して読むべきです。</para>
</section>
@ -74,8 +75,9 @@
プログラムにバグを見つけた! と思い込んでしまうことがあるでしょう
(とは言っても、それ自身、文書が適切に記述されていなかったり、
アプリケーションのエラー処理が甘いことを暗示している可能性があります)。
それ以外にも、障害報告を提出することが正しい行動では<emphasis>なく</emphasis>、
あなたや開発者たちに不満を抱かせるだけという場合があります
それ以外にも、
障害報告を提出することが正しい行動では<emphasis>なく</emphasis>、
あなたと開発者両方に不満を抱かせるだけという場合があります
(訳注: はっきりと把握していないことを報告すべきではありません。
要領を得ない障害報告は扱いにくいものです)。
逆に、バグではありませんが障害報告を提出するのにふさわしい場合もあります
@ -87,7 +89,7 @@
簡単な経験則では、それを質問として (よくあるのは
<quote>どうすれば X できますか?</quote> や
<quote>Y はどこで見つけることができますか?</quote> のような形式で)
表現できるなら、あなたの問題はバグでは<emphasis>ありません</emphasis>。
表現できるなら、問題はバグでは<emphasis>ありません</emphasis>。
いつも白黒がつけられるわけではありませんが、
この質問規則は大半の場合にあてはまります。
もし、このような質問に対する答えを求めているのなら、
@ -183,14 +185,14 @@
そのほとんどは &os; が書いたものではありません。
&os; が提供しているのは、
単なるアプリケーションをインストールする枠組みです。
したがって、問題が &os; 特有であると信じられる場合にだけ
したがって、問題が &os; 特有であると考えられる場合にだけ
&os; 開発者に報告してください。
それ以外は、そのソフトウェアの開発者に連絡してください。</para>
</listitem>
</itemizedlist>
<para>それから、問題が時宜を得たものか確認すべきです。
<para>それから、問題が時宜を得たものかを確認してください。
既に修正したバグに関する障害報告を受けとることほど開発者を悩ませるものはまずありません。</para>
<para>ベースシステムの問題で、&os;
@ -272,10 +274,10 @@
<listitem>
<para>何よりもまず、
元となるソースコード内のドキュメントで、
あなたの問題が触れられていないか調べてみるべきです。</para>
あなたの問題が触れられていないどうかを調べてみてください。</para>
<para>&os; の基本部分のコードについては、
システムの <filename>/usr/src/UPDATING</filename> ファイルの内容か、
システムの <filename>/usr/src/UPDATING</filename> の内容か、
<uri xlink:href="http://svnweb.freebsd.org/base/head/UPDATING?view=log">http://svnweb.freebsd.org/base/head/UPDATING?view=log</uri>
にある最新版をよく調べるべきです
(あるバージョンから別のバージョンにアップグレードしようとしているのであれば
@ -304,7 +306,7 @@
障害報告を作成して送信するプログラムの仕組みに入る前に、
障害報告をもっとも効果的なものにするこつをいくつか紹介しましょう。</para>
<section>
<section xml:id="pr-writing-tips">
<title>よい障害報告を書くこつ</title>
<itemizedlist>
@ -372,8 +374,8 @@
<para>&os; のバージョン
(これを記載する場所があります。後述します)
と、どのアーキテクチャで動かしているのかを書いてください。
動かしているのが (CDROM から、またはダウンロードして入れた)
リリースでなのか、それとも
動かしているのが (<acronym>CDROM</acronym> から、
またはダウンロードして入れた) リリースでなのか、それとも
Subversion でメンテナンスしているシステムでなのか
(そうだとしたら、最後に更新したのはいつか)
も書いてください。あなたが &os.current;
@ -523,7 +525,7 @@
</itemizedlist>
</section>
<section>
<section xml:id="pr-writing-before-beginning">
<title>始める前に</title>
<para>&man.send-pr.1; プログラムを使うなら、環境変数
@ -540,7 +542,7 @@
<uri xlink:href="&url.books.handbook;/mail.html">&url.books.handbook;/mail.html</uri>
をご覧ください。</para>
<para>あなたが使っているメーラが GNATS
<para>使用しているメーラが GNATS
に送るメッセージに手を加えないことを確かめておいてください。
特に、メーラが自動で改行したり、タブをスペースに変更したり、
改行文字をエスケープしたりすると、
@ -549,8 +551,7 @@
で表示した時に読みやすいように、
70 文字前後で改行を入れることをお願いしています。</para>
<para>&man.send-pr.1; の代わりに
<link xlink:href="&url.base;/send-pr.html">web
<para><link xlink:href="&url.base;/send-pr.html">web
ベースの障害報告提出フォーム</link>
を利用する場合も、同様の配慮が必要です。
カットアンドペースト操作はテキストをフォーマットするのに副作用がある場合があるので気をつけてください。
@ -564,7 +565,7 @@
フォーム</link> で問題になります。</para>
</section>
<section>
<section xml:id="pr-writing-attaching-patches">
<title>パッチやファイルを添付する</title>
<para>以下は、障害報告を電子メールで提出する場合にあてはまります。</para>
@ -582,10 +583,10 @@
<para>添付するファイルがバイナリであっても心配しないでください。
メールエージェントが混乱しないように、自動的に符合化されます。</para>
<para>パッチは context 形式か unified 形式の差分を &man.diff.1; の
<para>パッチを添付する場合、
パッチは context 形式か unified 形式の差分を &man.diff.1; の
<option>-c</option> か <option>-u</option>
オプションを使って作成してください (unified 形式の方が好まれます)。
パッチを添付する場合、
開発者があなたの報告を読んで簡単にパッチを適用できるように、
修正したファイルの正確な SVN のリビジョン番号が特定できるか確認してください。
カーネルやベースのユーティリティに関しては、新しいコードはすべて
@ -624,12 +625,12 @@
ライセンス下にあるものと仮定されることに留意しておくべきです。</para>
</section>
<section>
<section xml:id="pr-writing-filling-template">
<title>テンプレートに記入する</title>
<para>次の節は電子メール方式にのみあてはまります。</para>
<para>&man.send-pr.1; を動かすとテンプレートが表示されます。
<para>&man.send-pr.1; を動かすと、テンプレートが表示されます。
テンプレートは特定の項目から成り立っており、
その一部にはあらかじめ埋められていたり、
その項目の目的の解説やそこに記入できる値の一覧が記載されていたりします。
@ -816,20 +817,20 @@
まず最初に、それらのプログラムがベースシステムのものか、
もしくは Ports Collection から追加されたものなのかを判断してください。
よくわかならければ、
<command>whereis programname</command>
<command>whereis <replaceable>programname</replaceable></command>
と実行してください。
&os; の Ports Collection の慣例では、
(システム管理者は、この設定を変更することができますが) すべてのものは
<filename>/usr/local</filename>
<filename class="directory">/usr/local</filename>
以下にインストールされます。
このような場合は、<literal>ports</literal> カテゴリを使うことになります
(もし、その port のカテゴリが <literal>www</literal>
であっても当てはまります。説明が下にあります)。
もし、コマンドの場所が
<filename>/bin</filename>,
<filename>/usr/bin</filename>,
<filename>/sbin</filename> もしくは
<filename>/usr/sbin</filename> であれば、
<filename class="directory">/bin</filename>,
<filename class="directory">/usr/bin</filename>,
<filename class="directory">/sbin</filename>, もしくは
<filename class="directory">/usr/sbin</filename> であれば、
それはベースシステムの一部ですので、
<literal>bin</literal> カテゴリを使ってください
(&man.gcc.1; のようないくつかのプログラムでは、<literal>gnu</literal>
@ -860,7 +861,7 @@
<note>
<para>もし、問題が
<literal>www/someportname</literal>
<literal>www/<replaceable>someportname</replaceable></literal>
という名前の port に関連したものであっても、
<literal>ports</literal> カテゴリを選択してください。</para>
</note>
@ -1132,7 +1133,7 @@
</itemizedlist>
</section>
<section>
<section xml:id="pr-writing-sending">
<title>障害報告を送信する</title>
<para>&man.send-pr.1; を使っている場合</para>