Linux-HAプロジェクトでは、このwikiを補完するためにhttp://www.osdl.org/developer_bugzilla/ に、パブリックBugzillaを設けています(OSDLのご提供)。このページでは、Bugzillaの最も効果的な活用法、およびWikiとBugzillaの相互作用が実際にどのように働くのかについてのヒントを掲載しています。
Bugzillaの用途は、当然のことながら、Heartbeatのリリース済みバージョンのバグを追跡することです。すべてのバグはここに登録されることになります。バグを報告するユーザーはユーザー登録後に自分でバグを登録するか、(自分で登録するのが希望されない場合は)メーリングリストにバグを投稿することができます。その上で、開発者がBugzillaへとフィルタ処理をして、トラッキングと解決を目指すことになります。
まずは自分が実行しているリリースシリーズの最新バージョンで、バグの再現を必ず試みてください。1.0を実行している場合、1.2へのアップグレードを検討してください。特に、開発用の1.99.xバージョンを実行中の場合は、最新バージョンをお試しください。
当該動作を再現するために必要なステップと、本来行われるべき動作を正確に 説明してください。
両方のノードから関連する設定ファイル(少なくともha.cf, haresources, authkeys と、Heartbeatの起動からバグ発生に至るまでのログファイルの抜粋を添付してください。
http://www.grassouille.org/blogmax/041009.html.
自己注記:何も失われないよう、自動的にデータを収集するheartbeat-bug-reporterツールを提供するべきかもしれません。
バグの追跡のほか、実装に至っていない機能を追跡するために、Bugzillaを使用しています。Bugzillaは、誰が現在作業にあたっているかや、誰が質問を回したかといったことを文書に記録するうえで、非常に役立ちます。
バージョン番号は、当該機能の完成を見込んでいるバージョンの番号を反映する必要があります。バージョン番号とその日付の概要については、 Heartbeatロードマップ をご覧ください。
重大度については、常識的に使ってください。 blockerとは、所定のバージョン番号が、それが完成するまではリリースできないことを意味しますので、慎重に使う必要があります。
Bugzillaは、機能に関する込み入った議論には不向きであることが、経験から分かっています。Bugzillaのエントリは、Wiki上に記載した機能の詳細説明を参照し、議論自体はメーリングリストで行われるべきです。
バグは、誰も対応にあたっていない限り、つまり誰が担当すべきか決めるまでの間は、NEWの状態に置かれることになります。適当な人物が引き受けて対応を開始し次第、ASSIGNEDの状態に移されます。