path: root/files/ja/orphaned/bugzilla-jp/guide/lifecycle/mozilla/index.html

---
title: Mozilla
slug: Bugzilla-jp/Guide/LifeCycle/Mozilla
---
<p>
</p>
<h3 id="Mozilla.E9.96.A2.E9.80.A3.E8.A3.BD.E5.93.81.E3.81.AB.E9.96.A2.E3.81.99.E3.82.8B.E3.83.90.E3.82.B0.E3.81.AE.E3.83.A9.E3.82.A4.E3.83.95.E3.82.B5.E3.82.A4.E3.82.AF.E3.83.AB"> Mozilla関連製品に関するバグのライフサイクル </h3>
<p>Mozilla関連製品のバグとは、Core、Firefox、Thunderbird、Camino、Mozilla Application Suite、Calendar、L10N(日本語化)プロダクトのバグのことを指します。
</p><p><b>これらのプロダクトのステータスはTrunkでの開発状況を示します。これはBugzilla-jpで修正済みであるとされたバグであっても、次にリリースされる公式のビルドで修正されているとは限らないことに注意してください。</b>
</p><p>これらのバグで行われる作業とは、報告されたバグの確認とテスト、Bugzilla-orgの該当バグとの関連づけと、その追跡です。担当者はバグを修正するのではなく、そのバグの状態を追跡するのが仕事です。
</p><p>処理方法の各意味は次のように定義されています。
</p>
<h4 id="FIXED"> FIXED </h4>
<p>このバグはTrunkにおいて修正済みです。
</p>
<h4 id="WORKSFORME"> WORKSFORME </h4>
<p>このバグはTrunkにおいて再現しません。もしくは、報告者以外の環境で再現しませんでした。
</p>
<h4 id="INVALID"> INVALID </h4>
<p>このバグはバグではありません(仕様通りです)。または、INCOMPLETE導入前のバグで、何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。)
</p>
<h4 id="INCOMPLETE"> INCOMPLETE </h4>
<p>何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。)
</p>
<h4 id="WONTFIX"> WONTFIX </h4>
<p>このバグはバグですが修正されません。標準仕様がまずい場合や、実装するとパフォーマンスが著しく低下してしまうような場合、修正が著しく困難な場合、要望が受け入れられない場合等に用いられます。
</p>
<h4 id="OBSOLETE"> OBSOLETE </h4>
<p>このバグは修正された訳ではありませんが、再現不可能になっています。バグが再現していた条件がサポート対象外となった場合や、設計変更等により、そのバグが発生していた要件が揃わなくなった場合に用いられます。
</p>
<h4 id="DUPLICATE"> DUPLICATE </h4>
<p>このバグは別のバグと同じ内容でした。
</p>
<h4 id="LATER"> LATER </h4>
<p>使用しません。
</p>
<h4 id="REMIND"> REMIND </h4>
<p>使用しません。
</p>
&lt;hr&gt;
<p>これらのプロダクトでは、担当の決定までのプロセスで、
報告のされ方から三つのパターンが考えられます。
</p><p>一つめは、Trunkの最新のNightly Buildで確認されたバグを報告されたものです。
このバグは大抵の場合、すぐにスタッフによって確認が行われ、バグが確認されるとNEWになり、スタッフがBugzilla-orgから該当のバグを探す作業に入ります。Bugzilla-orgで該当のバグが発見されると、発見した人か、別のスタッフがバグの担当に就任し、ASSIGNEDとなり、Bugzilla-orgの該当バグの追跡を開始します。
</p><p>もし発見できなかった場合は新たにBugzilla-orgにバグを報告し、報告者が担当に就任してBugzilla-orgの該当バグの追跡を開始します。
</p><p>二つめは、最新のリリースビルドを使って確認されたバグを報告されたものです。このバグの場合、Trunkの最新のNightly Buildで再現確認が行われます。もし、再現した場合は一つめのケースと同様に処理されることになります。しかし、再現しなかった場合は少し面倒です。
</p><p>まず、同じリリースビルドで再現するかどうかが確認されます。もし、ここで確認された場合、Trunkでは修正されているということで、Bugzilla-orgで該当の修正済みのバグを探すことになります。
</p><p>もし、バグが見つかれば、Bugzilla-orgのバグがREOPENEDに戻らないか、監視するために誰かが担当に就任して、そのままRESOLVED FIXEDとなります。見つからなかった場合は、担当者不在のまま、RESOLVED WORKSFORMEとなります。
</p><p>もし、リリースビルドでも再現できなかった場合は報告者とのやりとりによって、再現に努めることになりますが、適当な所で作業が打ち切られて、RESOLVED WORKSFORMEもしくは、RESOLVED INVALIDとなることもあります。
</p><p>三つめは、Bugzilla-orgに報告されていて、再現するバグをBugzilla-orgのバグID付きで報告される場合です。この場合、報告者がそのまま担当に就任するか、スタッフが担当に就任し、ASSIGNEDとなります。
</p><p>担当者によりバグの追跡が開始されると、多くの場合、そのバグの更新は修正されるまで停滞することになります。日本人開発者がそのバグの修正に取りかかった場合、日本人間でのディスカッションが必要ならそのバグで議論が行われますが、それは希です。
</p><p>Bugzilla-orgの関連したバグで何らかの動きがあれば、担当者はその動きを報告してくれるかもしれません。しかし、担当者にその義務はありませんので、担当者次第です。リアルタイムに情報が欲しい場合は関連づけられたBugzilla-orgのバグを自分で追跡する必要があります。
</p><p>Bugzilla-orgの該当バグがRESOLVEDになった場合、その結果によって以下の四つの対処が担当者によって行われます。
</p><p>一つめは、Bugzilla-orgでFIXEDまたは、WORKSFORMEとなった場合です。この場合、担当者はバグのホワイトボードに<span>Bug-org [Bugzilla-orgのバグの番号] [FIXED|WORKSFORME]</span>と、関連バグの処理結果をメモします。
</p><p>そして、担当者、またはテストできる人間が、バグの修正、または、再現しないことを確認すると、Bugzilla-orgと同様の処理方法で、RESOLVEDとします。また、同時に、修正されたタイミングを明確化させるために、現在のTrunkのサイクルから適切な値をターゲットマイルストーンに設定します。
</p><p>さらに別のスタッフ、もしくは報告者自身が修正を確認した場合、VERIFIEDとなります。
</p><p>もし、修正を確認できなかった場合、関連づけていたBugzilla-orgとは関係なかった可能性があるので再調査となります。
</p><p>二つめは、Bugzilla-orgでINVALIDまたはWONTFIXとなった場合です。この場合、担当者はバグのホワイトボードに<span>Bug-org [Bugzilla-orgのバグの番号] [INVALID|WONTFIX]</span>と、関連バグの処理結果をメモし、その根拠となったコメントを要約(翻訳)して、その理由をBugzilla-jp上でも明記し、Bugzilla-orgと同様の処理方法で、RESOLVEDとします。さらに別のスタッフがその根拠を受け入れた場合、VERIFIEDとなります。
</p><p>もしスタッフ以外でこの結果に納得できない人がいる場合、
その人はスタッフに事情を説明して説得するか、
直にBugzilla-orgの担当者と英語でディスカッションする必要があります。
</p><p>三つめは日本人開発者がバグを修正した場合です。この場合、ホワイトボードに一つめの場合と同様の記述を行い、直ちにRESOLVED FIXEDとなります。これは、バグの修正課程において日本人の環境下でその修正がテストされているためです。
</p><p>後に、別のスタッフが修正を確認するとVERIFIEDとなります。
</p><p>四つめは関連づけていたBugzilla-orgのバグがRESOLVED DUPLICATEとなった場合です。この場合、担当者は新たに重複していた元のバグの監視を継続することになります。
</p>