[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Misc/pr-hints.html: 1.29
以下のページの翻訳をしました。ツッコミをお願いします。
Misc/pr-hints.html: 1.29
月曜日までに異議がなければ、 commit します。
原文は
http://cvsweb.netbsd.org/bsdweb.cgi/%7Echeckout%7E/htdocs/Misc/pr-hints.html?rev=1.29&content-type=text/html
で、訳文は
http://www.na.rim.or.jp/%7Ekano/tmp/Misc/pr-hints.html
に置いてあります。
以下は原文との差分です。
--- pr-hints.html.orig Sun Oct 31 11:30:00 2004
+++ pr-hints.html Fri Sep 2 06:32:18 2005
@@ -1,118 +1,114 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<html>
+<html lang="ja">
<head>
<!-- Copyright (c) 1994-2003
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED. -->
-<link rev="made" href="mailto:www@NetBSD.org">
+<meta http-equiv=content-type content="text/html; charset=ISO-2022-JP">
+<link rev="made" href="mailto:www@jp.NetBSD.org">
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
-<title>What Goes In A Problem Report</title>
+<title>問題報告の書き方</title>
</head>
<body bgcolor="#FFFFFF" text="#000000">
-<h1><a name="page-top">What Goes In A Problem Report</a></h1>
+<h1><a name="page-top">問題報告の書き方</a></h1>
<ul>
-<li><a href="#general-advice">General Advice</a></li>
-<li><a href="#kernel-panic">When Reporting a Kernel Panic</a></li>
+<li><a href="#general-advice">一般的な助言</a></li>
+<li><a href="#kernel-panic">カーネルパニックを報告する場合</a></li>
</ul>
<p>
-A database is only as good as the data that goes into it.
-In general, common sense (assuming such an animal exists) dictates the
-kind of information that would be most helpful in tracking down and
-resolving problems in software.</P>
+データベースが有用になるかどうかは、含まれるデータ次第です。
+一般的に、ソフトウェアの問題を追跡したり解決したりするために、
+どんな種類の情報が最も有用となるかは、常識 (それを理解する動物が存在すると仮定して)
+で決まります。</P>
<p>
-<h2><a name="general-advice">General Advice</a></h2>
+<h2><a name="general-advice">一般的な助言</a></h2>
<ul>
-<li>Include anything <em>you</em> would want to know if you were
-looking at the report from the other end. There's no need to include
-every minute detail about your environment, although anything that
-might be different from someone else's environment should be included
-(your path, for instance).
-<p>
-
-<li>Narratives are often useful, given a certain degree of
-restraint. If a person responsible for a bug can see that A was
-executed, and then B and then C, knowing that sequence of events
-might trigger the realization of an intermediate step that was
-missing, or an extra step that might have changed the environment
-enough to cause a visible problem. Again, restraint is always in
-order ("I set the build running, went to get a cup of coffee
-(Columbian, cream but no sugar), talked to Sheila on the phone,
-and then THIS happened...") but be sure to include anything
-relevant.
+<li><em>あなた</em>が他人の報告を読む場合に必要とするであろう情報は、
+すべて記入します。あなたの環境の詳細について毎回書く必要はありませんが、
+他人の環境とは異なっているであろう部分
+(たとえばパス) はすべて書いてください。
+<p>
+
+<li>出来事をある程度絞って述べると、その情報は多くの場合、有用なものになります。
+A が実行されてから B が実行され、そして C が実行されたことがバグに対処できる人にわかれば、
+これらの事象のつながりが原因で失敗するような中間ステップを実現させうるとか、
+余計なステップが原因で問題を顕在化させるような環境の変化を引き起こしうる、
+ということがわかるかもしれません。
+繰り返しますが、内容を絞ることは常に望ましいことですが
+(「構築を実行するようにしてから、コーヒー (コロンビア、クリーム入り、砂糖抜き)
+を取りに行き、シーラと電話で話したのちに、*この問題* は起きた…」)、
+関連のある事項はすべて含めるようにしてください。
<p>
-<li>Richard Stallman writes,
+<li>Richard Stallman は次のように書いています。
<blockquote>
-The fundamental principle of reporting bugs usefully is this:
-<strong>report all the facts.</strong>
-If you are not sure whether to state a fact or leave it out, state it!
+有用なバグ報告の基本方針はこれだ:
+<strong>事実をすべて報告する。</strong>
+書くべきか書かざるべきか迷うのなら書きなさい!
</blockquote>
-This holds true across all problem reporting systems, for computer
-software or social injustice or motorcycle maintenance. It is
-especially important in the software field due to the major
-differences seemingly insignificant changes can make (a changed
-variable, a missing semicolon, etc.).
-<p>
-
-<li>Submit only <em>one</em> problem with each Problem Report.
-If you have multiple problems, use multiple PRs. This aids in
-tracking each problem and also in analyzing the problems associated
-with a given program.
-<p>
-
-<li>It never hurts to do a little research to find out if the
-bug you've found has already been reported. Most software releases
-contain lists of known bugs in the Release Notes which come with
-the software. In addition, it's a good idea to
-<a href="query-pr.html">search the NetBSD GNATS problem report database</a>
-to see if someone already reported the problem you're having (who knows?
-there might already be a fix or work-around in the database).
-<p>
-
-<li>The more closely a PR adheres to the standard format, the
-less interaction is required by a database administrator to route
-the information to the proper place. Keep in mind that anything
-that requires human interaction also requires time that might be
-better spent in actually fixing the problem. It is therefore in
-everyone's best interest that the information contained in a PR be
-as correct as possible (in both format and content) at the time of
-submission. See <a href="pr-fields.html">a description of the fields</a> in a
-problem report for more details.
+これは、コンピューターソフトウェア・社会不正・オートバイの保守など、
+あらゆる問題報告システムに通用することです。そしてこれは、一見些細な変化
+(変数の変更、セミコロンが足りない、などなど) が大きな違いをもたらしうる
+ソフトウェア分野では、特に重要なことです。
+<p>
+
+<li>各問題報告では、ただ<em>ひとつ</em>の問題を提出するようにしてください。
+複数の問題があれば、問題報告を複数に分けてください。こうすることで、
+各問題の追跡や、またそのプログラムに関連する問題の分析の助けとなります。
+<p>
+
+<li>報告前に、そのバグがすでに報告されているかどうか、
+ちょっと調べてみることは悪いことではありません。
+ほとんどのソフトウェアでは、
+既知のバグのリストが載ったリリースノートが附属しています。
+さらに、あなたが遭遇した問題がすでに報告されているかどうか、
+<a href="query-pr.html">NetBSD GNATS 問題報告データベースを検索する</a>
+のがよいでしょう (その問題を誰が知っているか?
+また、修正や回避策がデータベースにすでにあるかもしれません)。
+<p>
+
+<li>さらに、問題報告に限っていえば、データベース管理者が
+報告された情報を適切に振り分けるために労力を使わなくていいように、
+標準的な形式での報告が必要です。あらゆる人手や時間は、
+問題の修正そのものに使われるべきであることを念頭に置いてください。
+従って、もっとも重要なことは、報告の時点で、
+問題報告に含まれる情報をできるかぎり正確に (フォーマットと内容のいずれも)
+記述することです。より詳しくは、問題報告の
+<a href="pr-fields.html">項目の説明</a>
+を参照してください。
</ul>
<p>
-<h2><a name="kernel-panic">When Reporting a Kernel Panic</a></h2>
+<h2><a name="kernel-panic">カーネルパニックを報告する場合</a></h2>
<p>
-So, the kernel panic'd, and gave you a whole lot of hexadecimal numbers,
-and halted.
-It's important for you to report this event,
-since real operating systems should never crash or panic,
-unless the computer hardware fails egregiously
-(there's usually not much an OS can do about hardware failure).
-That leaves kernel bugs as the other cause of a panic, and
-we need to track down those bugs and squash them to make NetBSD
-even more stable and robust than it already is.
+カーネルがパニックし、 16 進の数字がたくさん出て、停止したとします。
+この現象の報告は重要です。
+本物のオペレーティングシステムは、ハードウェアに重大な問題がない限り、
+決してクラッシュやパニックを起こさないべきものだからです
+(ハードウェアの問題に対して OS ができることはほとんどありません)。
+このほかパニックの原因となるものとしてはカーネルのバグがありますが、 NetBSD
+をさらに安定かつ強堅にするため、問題を追跡してバグをつぶす必要があります。
<p>
-The trouble is that the stack dump that the kernel printed is
-specific to your kernel, and the numbers really have to be converted
-back into symbol table references so that someone else who doesn't have
-your system's kernel can get an accurate picture of where it decided to die.
+問題は、カーネルが出力するスタックダンプは、各カーネルに固有のもので
+あることです。そこで、この数字を実際のシンボルテーブルの参照に変換して、
+あなたのシステムのカーネルを持っていない人が
+カーネルがお亡くなりになった時点の正確な状況がわかるようにする必要があります。
<p>
-At a minimum, copy down the "PC" numbers and convert them to symbolic
-references - that's the <I>Program Counter</I> for the computer; where it
-was executing. Ideally, if you can arrange to cut & paste the
-whole thing, that's even better.
+少なくとも、 "PC" の数値をコピーしてシンボル参照に変換します
+- "PC" は、実行された時点のコンピューターの <I>プログラムカウンター</I> です;
+理想的には、すべてをカット & ペーストできれば、
+そうするほうが望ましいです。
<p>
-So, when the kernel gives you this (usually several lines of this):
+カーネルが、以下のように出力したとします (たいていはこれが複数行あります):
<p>
<samp>
@@ -120,11 +116,10 @@
</samp>
<p>
-The PC number is specific to the kernel you were running, and is not likely
-to be the same as anyone else's kernel, so it must be converted to a symbol
-reference.
-To convert a hexadecimal PC value to symbolic reference,
-use <cite>gdb(1)</cite>, in the following way:
+PC の数値はカーネル毎に固有のもので、別のカーネルでは異なるものになります。
+このため、シンボル参照に変換する必要があります。
+16 進の PC 値をシンボル参照に変換するため、
+以下のように <cite>gdb(1)</cite> を使います:
<p>
<pre><samp> gdb -k /netbsd
@@ -133,20 +128,19 @@
0xf80ff430 <cpu_reboot+196>: 0x40000093</samp></pre>
<p>
-That "<cpureboot+196>" result from <CITE>gdb(1)</CITE> is what the
-people who will work on the problem report will need, so put it
-(preferably along with the rest of that "args" line) into your
-problem report.
+<CITE>gdb(1)</CITE> で得られたこの "<cpureboot+196>" が、
+問題報告をもとに作業する人に必要ですので、これを
+(できれば残りの "args" 行も一緒に) 問題報告に含めてください。
<p>
-See
-<a href="http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=3765">problem
-report #3765</a> for an example of an exhaustive PR on a kernel panic.
+カーネルパニックの徹底的な問題報告の例としては、
+<a href="http://www.NetBSD.org/cgi-bin/query-pr-single.pl?number=3765">問題報告
+#3765</a> を参照してください。
<p>
<hr>
<a href="#page-top">[Page top]</a>
-<a href="../Gnats/">[GNATS summary]</a>
+<a href="../../Gnats/" origlink="../Gnats/">[GNATS summary]</a>
<a href="query-pr.html">[Query PR]</a>
<a href="pr-fields.html">[PR fields]</a>
<a href="pr-states.html">[PR states]</a>
@@ -154,19 +148,23 @@
<table><tr><td>
<a href="../"><img
- src="../images/NetBSD-flag.png" border=0
+ src="../../images/NetBSD-flag.png" origlink="../images/NetBSD-flag.png" border=0
width="90" height="90" alt=""></a>
</td><td>
<a href="../"><img
- src="../images/empty.gif" border=0
- width="1" height="1" alt="NetBSD">Home Page</a>
+ src="../../images/empty.gif" origlink="../images/empty.gif" border=0
+ width="1" height="1" alt="NetBSD">ホームページ</a>
</td></tr></table>
<hr>
<address>
<small>
- <a href="http://www.NetBSD.org/cgi-bin/feedback.cgi">(Contact us)</a>
+ (連絡先 - <a href="http://www.NetBSD.org/cgi-bin/feedback.cgi">英語</a>,
+ <a href="mailto:www@jp.NetBSD.org">日本語:
+ www@jp.NetBSD.org</a>)<br>
$NetBSD: pr-hints.html,v 1.29 2004/10/30 22:33:37 jschauma Exp $<br>
+ <!-- based on english translation: -->
+ <!-- NetBSD: pr-hints.html,v 1.29 2004/10/30 22:33:37 jschauma Exp -->
<a href="disclaimer.html">Copyright © 1994-2003
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.</a>
</small>