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

提供: VyOS jp
移動: 案内検索
17行: 17行:
 
When you are able to verify that it is actually a bug, spend some time to document how to reproduce the issue. This documentation can be invaluable. When you wish to have a developer fix a bug that you found, helping them reproduce the issue benefits everyone.  Be sure to include information about the hardware you are using, commands that you were running, any other activities that you may have been doing at the time.  This additional information can be very useful.
 
When you are able to verify that it is actually a bug, spend some time to document how to reproduce the issue. This documentation can be invaluable. When you wish to have a developer fix a bug that you found, helping them reproduce the issue benefits everyone.  Be sure to include information about the hardware you are using, commands that you were running, any other activities that you may have been doing at the time.  This additional information can be very useful.
  
# What were you attempting to achieve?
+
# 何を実現しようとしていましたか?
# What was the configuration prior to the change?
+
# 変更前の設定では問題ありませんでしたか?
# What commands did you use?
+
# どのようなコマンドを実行しましたか?
  
=== Include  output ===
+
=== 情報を取得してください ===
The output you get when you find a bug can provide lots of information.  If you get an error message on the screen, copy it exactly.  Having the exact message can provide detail that the developers can use.  Like wise if you have any log messages that also are from the time of the issue, include those.  They may also contain information that is helpful for the development team.
+
  
One handy command is the "show tech-support".  This will provide detailed information that can be used while troubleshooting.  One way to do this is to save it directly to an FTP or SCP server that you have.  You can use the following format to export the "show tech-support" file.
+
バグを見つけた時の出力結果から多くの情報を得る事が出来ます。
 +
画面上にエラーメッセージが表示されている場合は、それを正確にコピーします。
 +
正確なメッセージ内容であるほど、開発者が詳細な調査をするために利用する事が出来ます。
 +
同様に、問題発生時間からの全てのログメッセージを持っている場合、開発チームで役立つ多くの情報が含まれています。
  
<pre>
+
'''show tech-support'''という便利なコマンドがあります。
show tech-support save ftp://user:[email protected]/path/to/file
+
このコマンドは、問題の原因調査の際に役立つ詳細情報を取得する事が出来ます。
</pre>
+
また、詳細情報を取得するだけでなく、あなたが持っているFTPまたはSCPサーバに取得した情報を直接保存することも出来ます。
 +
例えば、'''show tech-support'''ファイルを保存するには次の様に行います。
  
'''Note''': "show tech-support" includes complete configuration, so it's likely to have a lot of sensitive information, so be very careful when uploading it somewhere, especially to public resources, including the bugzilla.
+
show tech-support save ftp://user:[email protected]/path/to/file
  
If your issue is with a specific command such as OSPF, use the output of that command instead.  This provides a smaller set of information for the developers to review. 
+
'''注意''':'''show tech-support'''には完全な設定が含まれていますので、多くの機密情報が含まれる可能性があります。このため、bugzillaを含め公共のリソースにアップロードする際は非常に慎重になる必要があります。
  
If you suspect some feature is not handling traffic correctly (e.g. dropping sessions it should not or corrupting packets), attach a traffic dump. You can do this right on your router by using operational command like
+
発見した問題が、OSPFの様に特定のコマンドを使用している場合、代わりに、そのコマンドの出力を使用します。
 +
これは再検討を行う開発者に対して、より細かな情報を提供します。
 +
 
 +
もし、発見した問題が、正しくトラフィックを制御していない疑いがある場合は、正確なトラフィックダンプを添付してください。(例:意図しないセッション破棄やパケットドロップ等)
 +
次の様なコマンドでトラフィックダンプを取得出来ます。
 
  show interfaces ethernet eth0 capture
 
  show interfaces ethernet eth0 capture
 +
  
 
== It is a bug and want to report it ==
 
== It is a bug and want to report it ==

2014年3月30日 (日) 04:40時点における版

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

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

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

それがバグである事を確認します

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

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

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

When you are able to verify that it is actually a bug, spend some time to document how to reproduce the issue. This documentation can be invaluable. When you wish to have a developer fix a bug that you found, helping them reproduce the issue benefits everyone. Be sure to include information about the hardware you are using, commands that you were running, any other activities that you may have been doing at the time. This additional information can be very useful.

  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


It is a bug and want to report it

Create an account on the VyOS bugtracker. VyOS bugtracker is at bugzilla.vyos.net.

Then log in and follow "New" link from the top panel. You will get a report form you should fill.

Write a summary

Make it short and clear. Like "IPv6 interface route can not be deleted when configured". Avoid phrases like "not working" (unless the feature is really not working at all which is not seen in stable releases).

Write a description

Description is a place for detailed information about but. Write what you have found on the previous step: what is the bug and how to reproduce it.

Choose 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.

General guideline for choosing severity is the following:

  • Text: Typos or other mistakes in messages the system produces.
  • Trivial: Does not break any functionality. E.g. wrong sorting of rule numbers.
  • Minor: Causes minor functionality loss, or has easy workaround.
  • Major: Causes major functionality loss, workaround is difficult.
  • Critical: Breaks feature functioning entirely.
  • Blocker: Block release, users can't continue using the system until it is fixed.

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.