バグの報告方法

提供: VyOS jp
移動: 案内検索

問題、IT専門用語で言う「バグ」は、多くのソフトウエアプロジェクトで発見されています。VyOSも例外ではありません。

全ての問題について開発者に報告してください。これにより開発者は不具合を知る事が出来ます。こういったフィードバックが無ければ、開発者は全てが正常に動作していると信じています。

バグを発見したら何をすべきですか?

それがバグである事を確認してください

あなたがバグを見つけたと思った時、既にそのバグが報告済みであるかどうか確認する事はとても良い事です。

  • そのシステムが正しく設定されている事を確認するためにドキュメントを再確認してください。
  • ユーザーグループに報告し、コミュニティのサポートを得てください。
  • IRCで質問してください。

バグの再現性がある事を確認してください

実際にバグである事を確認後、バグの再現や説明文の作成には時間がかかるかもしれません。 しかし、説明文の作成は非常に重要です。あなたが発見したバグの修正を求める場合、それらは開発者がバグを再現する手助けになります。 問題が発生したハードウエアの情報や実行したコマンド、問題発生時に実施した可能性がある他の作業内容を含める事を忘れないで下さい。 こうした追加情報は非常に役に立ちます。

  1. 何を実現しようとしていましたか?
  2. 変更前の設定では問題ありませんでしたか?
  3. どのようなコマンドを実行しましたか?

情報を取得してください

バグを見つけた時の出力結果から多くの情報を得る事が出来ます。 画面上にエラーメッセージが表示されている場合は、それを正確にコピーします。 正確なメッセージ内容であるほど、開発者が詳細な調査をするために利用する事が出来ます。 同様に、問題発生時間からの全てのログメッセージを持っている場合、開発チームで役立つ多くの情報が含まれています。

show tech-supportという便利なコマンドがあります。 このコマンドは、問題の原因調査の際に役立つ詳細情報を取得する事が出来ます。 また、詳細情報を取得するだけでなく、あなたが持っているFTPまたはSCPサーバに取得した情報を直接保存することも出来ます。

例えば、show tech-supportファイルを保存するには次の様に行います。

show tech-support save ftp://user:password@host/path/to/file

注意show tech-supportには完全な設定が含まれていますので、多くの機密情報が含まれる可能性があります。このため、bugzillaを含め公共のリソースにアップロードする際は非常に慎重になる必要があります。

発見した問題が、OSPFの様に特定のコマンドを使用している場合、代わりに、そのコマンドの出力を使用します。 これは再検討を行う開発者に対して、より細かな情報を提供します。

もし、発見した問題が、正しくトラフィックを制御していない疑いがある場合は、正確なトラフィックダンプを添付してください。(例:意図しないセッション破棄やパケットドロップ等)

次の様なコマンドでトラフィックダンプを取得出来ます。

show interfaces ethernet eth0 capture


バグである場合は報告をしてください

VyOSのバグトラッカーでアカウントを作成します。 VyOSのバグトラッカーは、bugzilla.vyos.netです。

ログインし、トップ画面から「"New"」リンクをクリックしてください。バグの報告者が記入する必要があるバグ報告フォームが表示されます。

概要(Summary)を記載します

「Summary」欄は端的に明確に記載してください。 例えば「IPv6インターフェースのルート削除が出来ません」の様に記載します。

「動作しません」といった単語は避けてください。(安定版で機能がまったく動作しない場合を除きます。)

説明(Description)を記載します

「Description」欄はバグに関する詳細な情報を記載する場所です。前項で見つけた内容を記載してください。

例えば、そのバグはどの様にして再現する事が出来ますか。

重大度(Severity)を選択します

バグを過大評価せず、適切な重大度を選択してください。

報告者自身にとっては最重要なバグかもしれません。しかし、重大度(Severity)は一般的な利用者の視点から設定されています。

重大度を選択する際の一般的なガイドラインは以下の通りです:

  • Text: タイプミスやその他システムが生成するメッセージ内の間違い
  • Trivial: いかなる機能も壊れない場合(例:ルール番号の誤ったソート)
  • Minor: マイナーな機能故障や、簡単な回避策がある場合
  • Major: メジャーな機能故障や、問題の回避が困難である場合
  • Critical: 機能が完全に壊れてしまう場合
  • Blocker: 該当の問題が修正されるまで、システムを継続して利用する事が出来ない場合

迷った場合は「未割り当て(unassigned)」のままにすれば、開発者の誰かが設定します。 ユーザーが設定した、重大度の高いバグから最初に閲覧されて修復されるとは考えないでください。

重大度と優先度は一緒ではありません。重大度は、いかに重要であるかではなく、どの程度悪い影響があるのかを示します。 例えば、Majorと設定されたバグであっても、稀な利用方法でのみ再現する場合は、多くの利用者に影響のあるMinorと設定されたバグを先に修正する可能性が高いです。

構成要素(Component)を選択します

必須項目です。明確に分からない場合は推測してください。この項目は後から容易に変更する事が出来ます。

添付ファイルなどの大きなファイルを追加します

「"Add an attachment"」ボタンをクリックし、添付するファイルを選択後、ファイルの説明を記載します。 トラフィックダンプや設定ファイル、テストケースなどを添付してください。


改善要求

機能強化や新機能の要望は、バグと同様に連絡しますが、重要度(Severity)は「機能拡張(enhancement)」と設定します。 将来の機能の提案を記載し、CLI構文を提案してください。

報告例

記載例です。開発者は下記の様な書き方を好みます。

Components: Foo
Severity: Major

Description: Foo fails to commit when service-type is set to "bar"

Comment:

#set service foo rule service-type "bar"
#commit
Fatal: can't use "bar".

Service-type options "quux" and "baz" do not cause errors.