OpenBSD Problem Reports

https://www.openbsd.org/report.htmlの OpenBSD Problem Reportsを読んだので、訳を試みておく。

OpenBSDの問題の報告

リリース済みのバージョンに関する問題の報告

リリース済みのバージョンについて、バグや問題を報告する前には、以下のチェックリストを確認してください。

1. まず、このリリースについてのパッチと正誤表を確認してください。
2. 次に、より新しいバージョンさリリースされていないか確認してください。
3. 最後に、各バージョン間の変更履歴を確認してください。

もしどれにもあなたの問題が含まれていなかった場合には、バグを報告する前にsendbug(1)コマンドについて学んでください。

currentの問題の報告

-releaseでも-stableでもなく、-currentのソースツリーにあなたの問題がある場合には、以下を確認してください。

1. 少なくとも2回、その問題をテストしてください。その時のソースコードは数日離れたものにしてください。
2. ソースツリーがコンパイルできないという問題は、それが長く続くのでなければ報告しないでください。この種の問題はあなたのミスであるか、作業中のソースツリーを利用してしまっていることがほとんどです。プロジェクトで働いている人は、少なくとも1日に1回はmake buildを実行しています。普通は異なるアーキテクチャーで1日に等も実行しています。
3. AnonCVSサーバーは、実際の作業中のソースツリーが反映されるのに数時間かかることを覚えておいてください。
4. 各バージョン間の変更履歴に既に掲載されていないか確認してください。
5. スナップショットを作る際には、十分に注意していますが、時にはミスをすることもあります。その場合は謝罪します。バグ報告を送るより、メーリングリストで話をする方が適切です。

問題報告

常にできる限り多くの情報を提供するようにしてください。問題をピンポイントに絞り込むようにしてください。問題を再現できる明確な手順を教えてください。なるべく正確で混乱を生まないよ言葉を使うようにしてください。このことは、特に再現の難しい問題の場合には重要です。問題を説明するのに「クラッシュする」や「私の組み立てたマシンで奇妙な割り込みの問題が起きた」といった文は役に立ちません。 (メーリングリストやその他の知識のある人の集まるフォーラムにおいて)他の人とコミュニケーションするには、あなたの抱える問題が新しいもので、できれば再現性のあるものであると分かってもらわなくてはなりません。壊れていたりサポートされていないハードウェアを使っていたり、ソフトウェアでサポートされていないビルドオプションを使っていたりすることによって生じる自分にしか関係しない問題ではないことを確認するようにしてください。

多くの労力の必要な修正を、問題が明確になり、良く理解するより前に開始しないでください。特にリリース作業中は主要なコードを変更することは禁止されています。もし多量のコードを書こうとする時は、メーリングリストに投稿して、他の人が既にその問題に対して作業していないか確認してください(重複する作業を避けるためです)。

以下の事項を全てのバグ報告に含めるようにしてください。

1. 問題を再現するのに必要な起動時からの正確な一連の作業を教えてください。これはその一連の作業の説明で完結するようにしてください。コマンドライン引数やデータの提供なしに、コマンド名だけ報告するのでは不十分です。バグを再現するのに特定の出来事の発生が必要であれば、それらを列挙してください。送ろうとする情報を最も単純にするようにしてみてください。しかしこれは必須ではありません。もしバグに再現性があるのであれば、他の状況でも問題になるはずです。
2. あなたの見たアウトプットを教えてください。単に「動かなかった」や「失敗した」と伝えるのは止めてください。エラーメッセージが表示されたのであれば、もしその内容が理解できなかったとしても、それを提示してください。もし、OpenBSDが特定のエラーでパニックしたのであれば、それを提示してください。あなたがテストした時には、プログラムがクラッシュしたり、他の明らかな不具合が発生したりしていても、プロジェクトのテスト環境では再現しないかもしれません。一番簡単なのは、可能であればターミナルからアウトプットをコピーして提示することです。
   2の補足
   注意: 致命的なエラーの場合には、エラーメッセージには全ての情報が含まれているかもしれません。このような場合には、システムログファイルへの出力も見てください。これは/var/logディレクトリーに格納されています。また、アプリケーションソフトウェアは、httpdのように自分自身でログを記録しているかもしれません。そちらのログにエラーが記録されていないかも確認してください。
3. OpenBSDカーネルのアウトプットを教えてください。これがdmesgコマンドで取得できます。もしdmesgコマンドの出力が全ての情報を含んでいない場合には、/var/run/dmesg.bootファイルの内容も確認してください。この場合には、dmesgのアウトプットと/var/run/dmesg.bootの両方を含めてください。OpenBSDカーネルのアウトプットは全てのバグ報告で必須です。
4. サードパーティーのソフトウェアを動かしていて、それがバグに関連している場合、そのバージョンも教えてください。もし、スナップショットを使っているのであれば、その旨を書いた上で、日時も教えてください。
5. カーネルパニックからのバックトレース結果を教えてください。もし、カーネルがパニックしてddb(4)プロンプトに移行した場合、パニックメッセージと一緒にtraceコマンドの実行結果とpsコマンドの実行結果を含めることをおすすめします。マシンがハングしているのであれば、sysctl ddb.console=1をハングするより前で設定し、Ctrl+Alt+Escをキーボードで入力し、DDBに移行してください(この時はXの画面であってはいけません)。シリアルコンソールの場合には、BREAKを送信してください。パニックメッセージは見えない時には、show panicコマンドで再表示されることができます。これは可能であれば、いつでも含めるようにしてください。パニックメッセージとtraceコマンドの実行結果、psコマンドの実行結果のないカーネルパニックの報告は無意味です。show registerコマンドの実行結果も役に立ちます。boot dumpコマンドで再起動すれば、カーネルイメージはsavecore(8)によって保存され、crash(8)のマニュアルページに説明されているように、後でデバッグすることができます。
6. X.orgサーバーを使っているアーキテクチャーで、X window systemに関連する問題を報告する場合には、/var/log/Xorg.0.logファイルの内容をdmesg.bootファイルの内容と合わせて教えてください。

バグ報告が長くなっても気にしないでください。そういうものです。最初に全てを報告してしぼり込んでいく方が良いです。しかし、あなたの使っている入力ファイルがとても大きい容量であれば、誰かが興味を持って見てくれるか、最初に聞くことも許されます。

バグ報告を送る

可能であれば、sendbug(1)コマンドをバグ報告を作成するのを助けるために使用してください。sendbug(1)コマンドは、自動的にハードウェアに関する有用な情報を取得してくれます。この情報は多くの問題を診断するのに役立ちます。このツールを使うには、あなたのマシンが適切に電子メールを送ることができることが必要です。もし正常に動くOpenBSDマシンでsendbug(1)コマンドを使うことができないならば、バグ報告をbug@OpenBSD.orgへ送ってください。

バグ報告ではなく、新機能の要望を送ることもあるかもしれません。新機能についても受け付けます。新機能を実装したコードがあれば歓迎します。

問題によっては、デバッグするのにハードウェアが必要になる場合があります。OpenBSDプロジェクトのリソースは限られているのを覚えておいてください。ハードウェアを寄付することが可能です。