「バグの報告方法」の版間の差分

提供: VyOS jp
移動: 案内検索
3行: 3行:
 
全ての問題について開発者に報告してください。これにより開発者は不具合を知る事が出来ます。こういったフィードバックが無ければ、開発者は全てが正常に動作していると信じています。
 
全ての問題について開発者に報告してください。これにより開発者は不具合を知る事が出来ます。こういったフィードバックが無ければ、開発者は全てが正常に動作していると信じています。
  
== 私はバグを発見したら何をすべきですか? ==
+
== バグを発見したら何をすべきですか? ==
  
 
=== それがバグである事を確認してください ===
 
=== それがバグである事を確認してください ===
56行: 56行:
 
ログインし、トップ画面から「"New"」リンクをクリックしてください。バグの報告者が記入する必要があるバグ報告フォームが表示されます。
 
ログインし、トップ画面から「"New"」リンクをクリックしてください。バグの報告者が記入する必要があるバグ報告フォームが表示されます。
  
=== バグの概要(Summary)を記載します ===
+
=== 概要(Summary)を記載します ===
端的に明確に記載してください。
+
「Summary」欄は端的に明確に記載してください。
 
例えば「IPv6インターフェースのルート削除が出来ません」の様に記載します。
 
例えば「IPv6インターフェースのルート削除が出来ません」の様に記載します。
 +
 
「動作しません」といった単語は避けてください。(安定版で機能がまったく動作しない場合を除きます。)
 
「動作しません」といった単語は避けてください。(安定版で機能がまったく動作しない場合を除きます。)
  
=== バグの説明(description)を記載します ===
+
=== 説明(Description)を記載します ===
 
「Description」欄はバグに関する詳細な情報を記載する場所です。前項で見つけた内容を記載してください。
 
「Description」欄はバグに関する詳細な情報を記載する場所です。前項で見つけた内容を記載してください。
  
 
例えば、そのバグはどの様にして再現する事が出来ますか。
 
例えば、そのバグはどの様にして再現する事が出来ますか。
  
=== 重要度を選択します ===
+
=== 重大度(Severity)を選択します ===
Do not overestimate it. There are not as important bugs for you as your own, but severity is is set from the point of view of users in general.
+
バグを過大評価せず、適切な重大度を選択してください。
 +
 
 +
報告者自身にとっては最重要なバグかもしれません。しかし、重大度(Severity)は一般的な利用者の視点から設定されています。
  
General guideline for choosing severity is the following:
+
重大度を選択する際の一般的なガイドラインは以下の通りです:
* Text: Typos or other mistakes in messages the system produces.
+
* Text: タイプミスやその他システムが生成するメッセージ内の間違い
* Trivial: Does not break any functionality. E.g. wrong sorting of rule numbers.
+
* Trivial: いかなる機能も壊れない場合(例:ルール番号の誤ったソート)
* Minor: Causes minor functionality loss, or has easy workaround.
+
* Minor: マイナーな機能故障や、簡単な回避策がある場合
* Major: Causes major functionality loss, workaround is difficult.
+
* Major: メジャーな機能故障や、問題の回避が困難である場合
* Critical: Breaks feature functioning entirely.
+
* Critical: 機能が完全に壊れてしまう場合
* Blocker: Block release, users can't continue using the system until it is fixed.
+
* Blocker: 該当の問題が修正されるまで、システムを継続して利用する事が出来ない場合
  
 
Leave it "unassigned" if in doubt, someone of the developers will set it. Do not think bugs with higher severity set by user are viewed or fixed first.
 
Leave it "unassigned" if in doubt, someone of the developers will set it. Do not think bugs with higher severity set by user are viewed or fixed first.

2014年4月3日 (木) 15:46時点における版

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

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

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

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

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

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

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

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

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

情報を取得してください

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

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

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

show tech-support save ftp://user:[email protected]/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: 該当の問題が修正されるまで、システムを継続して利用する事が出来ない場合

Leave it "unassigned" if in doubt, someone of the developers will set it. Do not think bugs with higher severity set by user are viewed or fixed first.

Severity is not the same to priority, it specifies how bad it is but not how important it is. For example, major bugs that appear in a rare use case are likely to be fixed after minor bugs that affect everyone.

Choose the component

This is required. If not sure, try to guess, it can be changed easily in the future.

Add large files as attachments

Click "Add an attachment" button, choose your file and set description. Description is mandatory. Traffic dumps, configuration files or test cases are added this way.

Enhancement requests

Requests for enhancements or new features are filed similar to bugs, but with severity set to "enhancement". Write your feature suggestion and propose CLI syntax.

Bug example

Mock example of a bug developers will like.

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.