問題を報告するには

release バージョンの問題の報告

1. 最初に、そのリリースに関係する パッチと注意をチェックします。
2. 次に、手に入れることができる もっと新しいリリースがあるか確かめます。
3. 最後に、OpenBSD のバージョン間で行われた変更をチェックします。

あなたの問題が見あたらないようなら、 バグレポートを提出する前に sendbug(1) に慣れておいてください。

また、望ましいバグレポートのタイプ以降も読んでください。

current バージョンの問題の報告

1. 何日かして更新されたソースで、少なくとも二回はその問題をテストしてください。
2. 長引かないかぎり、ソースツリーのコンパイルに関する問題は報告しないでください。 あなたがそういった問題に直面するとき、ほとんどの場合、 それは思い違いだったり、すでに対応のための作業が進行しています。 プロジェクトで作業をしている人は、少なくとも一日に一回、 普通は色々なアーキテクチャで一日に数回は make build をしています。
3. anoncvs サーバが更新されるのは ソースツリーに対する実際の作業のあとであることを覚えておいてください。
4. その問題が存在しているかどうか確かめるため、OpenBSD のバージョン間で行われた変更をチェックしてください。
5. スナップショットの作成には細心の注意が払われますが、ときどき間違いが起こり、 私たちの言い訳が増えます。バグレポートを提出するより、メーリングリストを講読したり、 そこで質問をしてみるほうがいいでしょう。

問題の報告書を作るには

多くの作業が求められる問題は、それを確実に理解するまで、 特に、コードの主だった部分を変更してはいけないリリース期間の間は、 修正を始めないでください。もし、かなりの量のコードを書こうとしているのなら、 ほかのだれかがその問題の作業をしていないか確認するため、 いろいろなフォーラムを調べてみてください (無駄な努力を防ぐため)。

以下の項目はすべてのバグレポートに含められるべきです。

1. 起動してからその問題を再現するまでに必要になる、正確な一連のステップ。 これは問題を再現するために必要とする情報をすべて含めるべきです。 コマンド名だけでは不十分であり、引数やその他の形でコマンドに与えた データの説明も必要です。いくつかの現象の積み重ねでバグが発現するなら、 それらの現象をリストアップしてください。例の大きさは必要最小限にするよう 求められていますが、これは絶対に必要というわけではありません。 そのバグが再現可能であれば、いずれにせよ、私たちはそれを発見するでしょう。

2. 得た出力。「動かなかった」「失敗した」だけの説明はやめてください。 エラーメッセージがあれば、たとえ理解できなくてもそれを教えてください。 何らかのエラー発生とともにパニックするのなら、どんなエラーだったかを書 いてください。まったく何も起こらなかったのなら、そう書いてください。た とえ、あなたのテストの結果がプログラムのクラッシュやそのほかの明白なも のであっても、こちらのテストでは再現できないかもしれません。 できれば、一番簡単なのは出力をターミナルからコピーすることです。

   注意：致命的なエラーの場合、得られるエラーメッセージは、 手に入れることができるすべての情報を含んでいなかったかもしれません。 そのときは、/var/log などに保存されている、 システムログファイルにある出力も見てください。 httpd などのように独自のログファイルを持っているアプリケーションでは、 アプリケーションが保存するログに記録されたエラーをチェックしてみてください。 (httpd の場合は /var/www/logs です)

3. OpenBSD のカーネル出力。dmesg コマンドによって得られますが、 dmesg 出力が /var/run/dmesg.boot に保存されたすべての情報を含まないことがあります。 そのときは、両方から得た情報を書いてください。 すべてのバグレポートにこれを書いてください。

4. 問題が起きたときにサードパーティ製ソフトウェアを実行していた場合は、 そう書いて、そのソフトウェアが持つサブバージョンをすべて書いてください。 CVS や FTP スナップショットなら、その日付と時刻を書いてください。

5. カーネルパニックからのトレースバック。カーネルがパニックして ddb> プロンプトにいるのであれば、trace と ps コマンドの出力だけでなく、参考としてパニックメッセージも提供してください。
   もしも、なんらかの理由でパニックメッセージが表示されないときは、 show panic コマンドを使うことで再度得ることができます。
   これはきわめて重要なことです。パニックメッセージや traceback, ps の出力を欠いたパニックレポートは使いものになりません。
   show registers の出力も重要かもしれません。 また、そのあとで、boot dump を使って再起動するのもいいかもしれません。そうすればカーネルイメージが savecore(8) によって保存されて、カーネルが異常終了したあとでもさらにデバッグできるようになります。

6. X.Org サーバを使用するアーキテクチャの X Window System のトラブルについて報告する場合には、報告の中に、dmesg.boot の情報に加えて /var/log/Xorg.0.log ファイルの内容を すべて含めるようにしてください。

バグレポートが非常に長くなってしまっても気にしないでください。 それが現実です。最初にすべてを報告してもらった方が、 何回もやりとりを繰り返すよりはましです。 一方で、入力ファイルが巨大なときは、 それを見てみたい人がいるかどうか最初に聞いてみたほうがいいでしょう。

最後に、バグレポートを書くときは混乱を招かない用語を選ぶようにしてください。

バグレポートの提出

私たちの追跡システムにバグを登録するため、可能なかぎり sendbug(1) コマンドを使ってください。 この web ページで追跡システムにアクセスできます。 sendbug はきちんとインターネットメールを送れるシステムを必要とします。sendbug を使える環境がない場合は、 バグレポートは bugs@openbsd.org に送ってください。

ひょっとすると、あなたが提出しようとしているレポートは機能面の要望であって、 必ずしもバグの報告ではないかもしれません。基本的に新しい機能の提案は受け入れられます。 特に、その新機能を実装するコードをつけて送れば、ずっと受け入れられやすくなるはずです。 もし、あなたの提案した新機能のコードをだれか別の人が書いたら、場合によっては提案の内容を誤解されて、 あなたには理解できないような代物となり果ててしまう可能性だってあります。

一部の問題のデバッグのためには、その問題があるハードウェアを持っていなければなりません。 しかし、OpenBSD プロジェクトの資源には限りがあることを覚えておいてください。 ハードウェアを寄付することもできます。

バグレポートの種類を望ましい順に並べると：

1. 再現可能な問題でソースの修正も一緒についているものが最高です。
2. ハードウェアやソフトウェアの構成に依存しない再現可能な 問題。
3. あなたのソフトウェアの構成に特有の再現可能な問題。
4. あなたのハードウェアの構成に特有の再現可能な問題。
5. 再現不能な問題。-- あるいは、再現したくない問題。