Mozilla のバグ
あなたは Netscape Communicator の問題でここに来たのでしょうか？ もしそうなら、ここに来るのは間違っています。 代わりに Netscape の テクニカルサポート サイト または Netscape バグ報告フォーム を使ってください。
あなたは Debian 製品の問題でここに来たのでしょうか？ もしそうなら、ここに来るのは間違っています。代わりに Debian の テクニカルサポート または バグ追跡システム を利用してください。
あなたは マイルストーンやナイトリービルド または、自分でコンパイルした Mozilla のバグをレポートしたいのでしょうか？ その場合は Bugzilla （日本語版） が mozilla.org の配布するソフトウェアのバグレポートを提出するところです。このページでは Bugzilla の機能を大まかに説明します。参考になるバグレポートの書き方ついては、バグ報告ガイドライン を参照してください。
Bugzilla って何？
Bugzilla （日本語版） は、バグのデータベースです。バグの報告を受け付け、そのバグを適切な開発者に割り当てます。開発者は Bugzilla を使って、作業の優先順位をつけたり、スケジューリングしたり、バグの依存性の追跡ができるだけでなく、予定リストを管理することもできます。
すべての「バグ」がバグ 【訳注：不具合】 というわけではありません。データベース項目の中には、 Enhancement Requests とか Requests For Enhancement （RFE） として知られているものもあります 【訳注：どちらも「機能拡張のリクエスト」という意味】 。RFE とは、深刻度の欄で「enhancement 【訳注：拡張】」に設定されたバグのことです。皆が「Bugzilla に登録された項目」を「バグ」と呼ぶので、RFE もおしなべてバグとして呼ばれることになったのです。
あなたが計画している作業を、拡張リクエストとして入力してみましょう。すると Bugzilla で登録したバグを追跡したり、他の人があなたの作業計画を確認したりできます。他の人があなたの計画を見て、作業の重複を回避したり、もしかしたら手助けを名乗り出てくれたり、フィードバックを寄せてくれるかもしれません。
Bugzilla のソースコードをお探しですか？ あなた自身のサーバに Bugzilla をセットアップしたい場合は、こちら から入手できます。
バグの分析
バグや RFE は、多くの項目から構成されています。その中のいくつかをここで紹介します。
- Component （コンポーネント）
- Mozilla アプリケーションは、ネットワークライブラリ、 JavaScript、レイアウトエンジンといった複数の異なるコンポーネントから構成されています。バグをどのコンポーネントに当てはめたら良いのか迷ったら、コンポーネントの種類 （日本語版） をよく読んでください。 コンポーネントの中にはよく似たものがあります。 例えば、table （テーブル） のレイアウトの問題は、Layout （レイアウト） ではなく HTML Tables （HTML テーブル） に割り当てなければなりません。ここで選ばれたコンポーネントによって、 Bugzilla で誰がバグを担当するのかが決まります。
- Status Whiteboard （ステータスホワイトボード）
- ステータスホワイトボードは、バグについての短いメモを書くために使います。
- Keywords （キーワード）
- この欄はさまざまな キーワード （日本語版） を記録するために使われます。たとえば、BugAThon ではバグにテストケースがあるのを判断するためにキーワードを使います （キーワード
testcaseを使います）。 helpwanted-
開発者は、この項目を使って
helpwanted【訳注：救援求む】 のお知らせを通知できます。あなたが担当しているバグや RFE の Keywords 欄にhelpwantedと書いてみましょう。すると何かできることを探している人がそれを見つけてくれるはずです。また 参加する ことに興味を持っている人が、 Bugzilla でhelpwantedのついたバグや RFE を検索できます。その中には、あなたの問題解決に役立つような専門知識や資源を持っている人がいるかもしれません。たとえば、あなたの使えないプラットフォームや知らない言語でのバグがあるときに、このキーワードをつけてみてください。
あるいは、ほかの開発者と同様に、おそらくあなたもバグで圧倒されます。バグの中には、他のものよりプライオリティが低いものもあるはずです。すぐには処理できないと判断したバグはにはすぐにでも
helpwantedとマークするよう心がけてください。異なる関心を持つ誰かがこれを読んで、あなたを手助けしてくれるかもしれません。バグ （や RFE） を
helpwantedとマークする場合、どういう作業が必要なのか、またもし可能なら、その作業はどうやれば良いのか明確に説明するコメントを必ず加えてください。問題と解決方法をうまく説明できれば、誰かが有効な解決法を思いつく可能性は増します。 - Target Milestone （目標とするマイルストーン）
- Mozilla プロジェクトでは、Mozilla の開発プロセスの計画立案にターゲットマイルストーンを使っています。バグが
mozilla1.3にマークされている場合、そのバグは早ければ Mozilla 1.3 で修正が完了する予定であることを意味します。この欄は、そのバグに責任を持つ人 （つまり担当者） 以外の人は触ってはいけません。 - Dependency （依存性）
- 他のバグが修正されるまで修正できないバグがある場合、それは依存があるといいます。どのようなバグでも、そのバグが依存するバグや、そのバグに依存するバグを一覧にすることができます。Bugzilla は、どのバグがどのバグに依存しているか、依存されているかを表す依存グラフを表示することができます。
- Attachment （添付）
- バグにファイルを添付すると非常に役立ちます。テストケースやスクリーンショット、エディタのログ などすべてが、バグの特定に役立ち、バグの再現作業を減らしてくれます。また、バグを修正したら、パッチを添付してください。パッチを添付することでそのパッチへの変更も追跡できるので、他の人がパッチを見つけてテストすることが楽になります。パッチを作るにあたっては、レポジトリにある元のファイルとあなたの変更点との相違点を含む diff ファイルを作成する必要があります。現在のディレクトリのすべてのファイルに対して、変更点を列挙したパッチファイルを生成するためには、次のようにしてください：
cvs diff -u > mypatch.diff
パッチを適用するためには、適切なディレクトリへ行き次のようにしてください：patch < bugpatch.diff
バグのライフサイクル
バグがはじめて報告された時、バグの状態は、誰がそれを報告したかに依ります。標準の新しい Bugzilla アカウントから報告されたバグは、UNCONFIRMED になります - つまり QA （品質保証） 担当者がそのバグ報告を読み、確かにそのバグが存在することを確認するまで NEW バグにならないということです。
ある程度 Bugzilla での作業経験があり、自分は NEW バグを作成できるのにふさわしいと思う場合は、Gerv にメールを送ってください。バグが NEW になると、開発者がバグを確認して、受理するか、誰か他の人に割り振るはずです。バグが 1 週間以上 New のままで作業がされていない場合は、Bugzilla は処置が講じられるまで、そのバグの所有者に電子メールで小言を送ります。バグが再び振り分けられるか、Component が変更されると、ステータスは再び NEW に戻ります。ステータスが NEW とは、バグが新しく報告されたという意味ではなく、特定の開発者の仕事として、新しく追加されたことを意味します。
さらなる追加権限が与えられると、バグのすべての欄を変更することができるようになります （標準ではわずかな変更しかできません）。バグのフィールドを変更するときには、作業内容やその理由を説明するコメントを入れるようにしてください。コンポーネントを変更したり、バグを再割り当てしたり、ファイルを添付したり、依存性 （Dependency） に追加したり、誰かを CC リストに加えたりしたときは、常にそれに対するメモを書いてください。誰かがバグを変更したりコメントを加えたりすると、その変更点を示す電子メールが、オーナーや報告者、CC リストのメンバー、バグに投票した人達に送られます （彼らが設定で送信機能を無効にしていない限り）。
Bugzilla で活発に活動している場合、QA のためのヘルプページ を参照してみてください。さまざまな参考になる資料や作業項目が掲載されています。
バグが修正されると RESOLVED （解決） とマークされ、次のような決定通知が与えられます。
FIXED- このバグへの修正がツリーにチェックインされ、
FIXEDとマークした人により検証されました。 INVALID- 記述された問題はバグではないか、 Mozilla のバグではありません。
WONTFIX- 記述された問題はずっと修正されないバグか、問題が "仕様" によるもので、バグではないことを示します。
DUPLICATE- 問題は、既存バグの重複です。バグを duplicate とマークするためには重複しているバグの番号が必要で、バグの description （説明） 欄にそのバグの重複バグであるとのコメントを追加してください。
WORKSFORME- その時点でのビルドでは、そのバグを再現するためにあらゆる試みをしましたが、再現できませんでした。後に追加情報が出てきたら、バグを re-open してください。さしあたってはバグを申請しておくに留めます、ということです。
QA （あなたも QA になれます - QA のためのヘルプページ を参照してください） は解決したバグを確認し、適切な処置がなされているかを確認するためのものです。皆が同意すれば、バグは VERIFIED にマークされます。製品が出荷されるまでバグがこの状態だった場合、バグはその時点で CLOSED にマークされます。バグは時には REOPENED となって戻ってくることがあります。
他の誰かのバグの状態を変更するときには、気を付けてください。あなた自身が変更するのではなく、替わりに、コメントの形で変更提案を記述し、バグオーナーにそれをレビューさせ、彼ら自身に変更させるするのが、最も良い方法です。例えば、あなたがあるバグがほかのバグの重複だと判断した場合は、Additional Comments （追加コメント） 欄にその旨を記述してください。
あなたが役立つコメントを他の人のバグにたくさんつければ、皆はあなたの判断を信用し、あなた自身で変更をするように求めてくるでしょう。しかし、そうではない場合は、注意深く、コメントだけするのがベストです。
Bugzilla はオープンソースソフトウェアです。Bugzilla のソースコードは Mozilla Public License の下でリリースされています。Bugzilla のソースを使って、あなたのプロジェクトでバグシステムを作りたい場合は、Bugzilla のウェブサイト を参照してください。