1.Bugzillaとは?
Bugzillaはデータベースを利用したバグ・トラッキング・システムです。ユーザーからのバグの報告や、それに対する開発者の対応がより円滑に行なわれること目的とした総合的なバグ管理システムです。ユーザーはBugzillaを通してバグの報告や検索を行ない、開発者やエンジニアはBugzilla上の情報を通して作業をすすめていくことになります。Bugzillaは本来の意味での"バグ"だけでなく、今後の機能追加要求やアップデート情報なども取り扱うことができるシステムです。
2.Bugzillaの対象パッケージと運用にあたっての注意事項 --御利用前に必ずお読み下さい--
<対象パッケージ>
Bugzillaによるバグトラックの対象となるのは、TurboLinux社のFTPサイトに存在するパッケージの中で以下の3点の要件を満たすものです。
・オープンソースのパッケージであること。
・商用パッケージ以外であること。
・コンパニオンとして扱われるパッケージ以外であること。
つまり、ソースコードが公開されていないパッケージや、商用パッケージ、またコンパニオンCDに含まれるパッケージなどはBugzillaによるバグトラックの対象とはなりません。
<運用上の注意事項>
バグはそれへの対処が終了した時点でCLOSEとなりますがそれ以外でも以下のようなケースでバグはクローズされます。
| TurboLinux社で再現できないケース |
報告されたバグでもTurboLinux社において再現できないケースには、原則として一定期間(30日間)を経た後にそのバグはCLOSEとされます。(新規に再現情報が追加されるなどバグ対処が進行している場合はこの限りではない。) |
| 報告者へコンタクト出来ないケース |
リプライが無いなど、報告者とのコンタクトがとれないことによりバグの調査継続が不可能なケースには一定期間(30日間)を経た後、バグをCLOSEとします。 |
| 報告内容がバグではないケース |
報告内容が本来のバグとはいえないケースではその バグは"Not Bug" としてCLOSEされます。典型的なケースとして、例えば報告内容が質問やサポートの依頼であった場合がそれにあたります。 |
| Feature Request |
報告された内容が機能追加要求である場合には、それに対する回答が実現した段階でCLOSEとなります。例えば、弊社からの回答が「将来のバージョンで機能追加」であれば、その機能が実際に追加された時点でCLOSEとなりますが、逆に回答が「機能変更の予定無し」ということであった場合にはその回答が出た時点で対応は終了したものとみなし、その時点で即CLOSEになります。 |
|
3.Bugzillaへのアクセス
http://bts.turbolinux.co.jp/bugtraq/ へアクセスして下さい。
ブラウザのロケール設定を変えれば、日本語／英語を切り替えてBugzillaを利用することも出来ます。
4.アカウントの作成
Bugzillaを幅広く利用するにあたってアカウントを作成する必要があります。アカウントを作成していない場合には、webページから作成して下さい。 アカウントの作成画面でE-mailアドレスと名前を入力して登録ボタンを押せば、入力したE-mailアドレスにパスワードが送られます。これでアカウントの作成は完了です。入力に使用したE-mailアドレスとパスワードを利用してBugzillaにログインして下さい。ログイン時にはクッキー情報が保存されますので、再度同じブラウザでアクセスした時には、そのクッキーの情報が失われていない限りログイン作業を繰り返す必要はありません。
5.メールアドレスの公開
アカウント作成時には、メールアドレスの公開について設定が可能です。メールアドレスを公開すると設定した場合には、Bugzillaの報告者フィールドとログフィールドにアカウントとして使用しているメールアドレスが記録されます。記録された情報は、第三者により参照が可能となります。
また、メールアドレスを公開している場合には、自分が報告したバグに関する更新があった場合に自動的に更新の通知を受け取ることができます。
メールアドレスを公開しないと設定した場合には、アカウントはシステムが割り振るユニークなID番号に置き換えて記録されますので、第三者がBugzilla上でメールアドレスを参照することはできなくなります。
また、メールアドレスを公開しないと設定した場合には、自分が報告したバグに関する更新があった場合にも自動的に通知されることはありませんので、報告したバグを定期的にチェックする必要があります。
なお、バグの報告後にメールアドレスの公開設定を変更することも可能です。ただし、すでにログフィールドに記録された情報は設定に関わらず、記録時の設定のままとなりますので、注意が必要です。
例えば、メールアドレスを公開する設定でバグ報告を行い、後から、メールアドレスを非公開に設定変更したとしてもログフィールドに記録されているメールアドレスは参照可能な状態のまま残ります。
勿論、メールアドレスを非公開に設定変更した後には、メールアドレスがログフィールドに追記されることはありません。また報告者フィールドに関しては、記録時の設定にかかわらず、現在の設定が有効となります。
6.Bugzillaの利用方法
Bugzillaの主な用途は以下の2点です。
・新規のバグの報告
・既存のバグの検索
ここでは上記2つに関して利用方法を述べていきます。尚、アカウントの種類によっては、Bugzillaの画面に表示される情報が、ここで述べる内容と一部違いがあることがありますので御了承下さい。
6.1新規バグの登録
http://bts.turbolinux.co.jp/bugtraq/ にアクセス後に表示される画面で『新規のバグの登録』(またはBugの登録ボタン)をクリックして下さい。 ログインを要求された場合には、作成したアカウント(E-mailアドレスとパスワード)でログインして下さい。
登録画面が表示されるはずです。
登録画面で入力、指定するフィールドは以下のようなものがあります。ただし、御使用のアカウントや製品の種類によっては入力の必要のないものもあります。
○製品
○製品バージョン
○Platform
○パッケージ
○バージョン／リリース
○Priority
○Severity
○Justification for P1
○調査担当
○Cc:
○URL
○現象要約
○詳細情報
○Defect Type
上記のフィールドのそれぞれのフィールド名をクリックするとヘルプ画面に表示が移り、何を入力、指定すればよいかは確認できますので、参考にして下さい。
主な項目への入力内容は以下のようになります。
| 製品 |
バグを報告するパッケージが含まれている製品を指定します。 |
| 製品バージョン |
製品のメジャー・バージョンを指定します。
例えばTurboLinux Server 6.1でバグが発生した場合には6を指定します。 |
| Platform |
バグが発生したシステムのプラットホームを記します。有効な値は以下の通りです。
x86
noarch |
| パッケージ |
バグ報告の対象となるパッケージ名を選択して下さい。 |
| バージョン/リリース |
新規にバグ登録をする際には通常、バージョンやリリース番号を指定する必要はありません。バグ情報の更新などにおいて、入力が必要となるケースではバージョンやリリース番号を入力して下さい。例えばバグの対象となるパッケージファイルの名前がpackage-1.2.3-10.i386.srpmの場合、バージョンは1.2.3、リリース番号は10になります。 |
| Priority |
バグの対応の優先度を表します。 このフィールドは、バグの調査を担当するプログラマやエンジニアがそれぞれの優先順位を判断するために使用されます。
指定できる値は以下のものです。
P1 システムダウン、セキュリティ関連の問題
P2 通常時のプライオリティ
P3 特殊条件で発生する問題
|
| Severity |
severityフィールドはbugの影響度を示すものです。
| Security |
セキュリティ関連の問題 |
| Normal |
通常の障害報告 |
| Enhancement |
機能追加要求 |
|
| Justification |
このフィールドはバグがプライオリティ1(P1)の時に記述する必要があります。プライオリティをP1として優先的に調査されるべきバグとして報告する場合には、その重要性を支えるだけの事由があるはずですのでそれを簡潔に記述して下さい。バグを至急に修正する必要性が、バグ担当者にすぐにわかるような内容が理想的です。 |
| Assigned To |
報告されているバグの調査担当者名が表示記されます。このフィールドが変更された時には、バグのステータスが変更されることがあります。 |
| Cc: |
登録するバグに関する情報を特定のメールアドレスに送信したい時に指定します。ここで入力したメールアドレスはbugzillaのログに残り、公開されますので、公にしたくないメールアドレスは指定しないで下さい。尚、このフィールドで指定できるのはBugzillaに登録されているアドレスのみです。Bugzillaにアカウントとして登録されていないメールアドレスを指定してもエラーになります。 |
| URL |
登録されるバグに関連する情報が参照できるWEBサイトにある場合には指定します。ただし、指定されたサイトが将来存在しなくなることも考えられるので、念のためサイト上の関連情報の部分を詳細フィールドにペーストして下さい。 |
| 現象要約 |
バグの内容を簡潔に記述します。担当者やその他の利用者が、このフィールドを見てバグの概要を把握できるような内容が理想的です。 |
| 詳細情報 |
バグの内容をできだけ詳しく記述して下さい。
バグに関連すると思われるパッケージのバージョン／リリース番号、再現させるための手順や、再現時のシステムの環境などを書くことが大切です。バグが適切に調査・修正されるためには、このフィールドの情報が十分であることが重要になるからです。 |
| Defect Type |
報告された内容が機能追加要求である場合には、それに対する回答が実現した段階でCLOSEとなります。例えば、弊社からの回答が「将来のバージョンで機能追加」であれば、その機能が実際に追加された時点でCLOSEとなりますが、逆に回答が「機能変更の予定無し」ということであった場合にはその回答が出た時点で対応は終了したものとみなし、その時点で即CLOSEになります。 |
|
6.2 既存のバグの検索
新規バグの登録と同様にBugzillaにアクセスし、『既存のバグの検索』(またはBugの検索ボタン)をクリックするとバグの検索画面が表示されます。 この画面ではさまざまな条件を指定してバグの検索が出来ます。
指定できる検索条件は以下のようなものです。ただしBugzillaのログインに御使用のアカウントや製品の種類によっては指定する必要のないものもあります。
○パッケージ
○製品バージョン
○バージョン／リリース
○Platform
○Priority
○Severity
○Justification
○調査担当
○Cc:
○URL
○現象要約
○詳細情報
○Defect Type
○報告者、QA担当者、CcリストのE-mailアドレス(正規表現も含む)
○更新の日付
○現象要約、回答要約、詳細情報、URL中の文字列(正規表現も含む)
また検索したバグ情報を更新するケースには、バグ解析の参考になるようなファイルをattachmentとして登録することもできます。
7.Bugzillaのその他の機能や用途
Bugzillaのその他の機能、用途について説明します。ただし、アカウントの種類により使用できる機能に制限があることがありますので御了承下さい。
7.1 サマリ・レポートの生成
Bugzillaのメニューで『サマリ・レポートの作成』を選択すると、Bugzillaに登録されているバグ情報に関するサマリ・レポートを作成することができます。
調査担当者ごとのバグ件数や、特定期間でのバグの発生件数や処理件数などをサマリ・レポートとして作成できます。
7.2 アップデート情報
Bugzillaのメニューで『アップデート情報の登録』を選択し、製品名を指定すると、パッケージに関するアップデート情報の入力画面が表示されます。入力の方法はバグ登録とほぼ同じです。
7.3 ブックマークに登録可能なテンプレートの作成
バグの登録画面や検索画面、またアップデート情報登録画面には『ブックマークに登録可能なテンプレートの作成』ボタンがあります。これを利用してバグ報告を行うためのテンプレートを作成することが出来ます。作成されたテンプレートのURLをブラウザのブックマークとして登録してご利用下さい。
8.バグのStatusとResolutio
| Status |
Resolution |
| Statusフィールドの値はは現在のバグのステータスを表します。 それぞれのステータスの意味は下記のようになります。 |
Resolutionフィールドはバグに対して行なわれた対応を示します。 |
Reported
バグが最初に報告された段階です。
担当者に受け付けられるのを待っています。
Open
バグが担当者に受け付けられ調査が開始された段階です。
|
左記に記したOpenとReportedのバグは解決されていませんのでResolutionのステータスはありません。 それ以外のバグは下に記すResolutionのうちの1つが表示されます。 |
To be verified
担当者により対応がとられたバグに関してQAが検証を行なう段階です。
Resolved
回答内容および、修正が承認され、報告されたバグが解決されたことを示しています。 |
Fixed
オリジナルのソースコード上で修正が反映されました。
Patched
パッチが適用されるなど、オリジナルのソースコードに含まれない修正により対応されました。
Update
オリジナルのパッケージが更新されたため、追従してパッケージが更新されました。
NotBug
報告されたバグは、バグではないと判断されました。例えば、「仕様通り」である場合や、バグ報告そのものが誤っている場合などです。
Pending
修正に対する影響の大きさや何らかの理由により、処置を保留としています。現バージョンの製品では解決されない可能性が高いですが、何らかの対策がとられる可能性も残っています。
Duplicate
このバグは既存のバグ報告の回答と重複します。または、既存のバグの派生現象として発生しています。オリジナルのバグを参照してください。
Workaround
バグそのものに対する修正はされませんでしたが、障害を回避するための一時的な修正や回避策がとられています。
CannotReproduce
バグの再現性が確認できず、修正などの対策がとられなかったことを示します。 |
|
|
