mozilla
Your Search Results

    What to do and what not to do in Bugzilla

    この文書は、バクを振り分けるための Bugzilla 権限の使用法についてのものです。そして、bugzilla.mozilla.org において、何をするべきか何をしてはいけないかを説明しています。

    Bugzilla の権限を取得・昇格する

    もし Bugzilla の権限 (下記をご参照ください) を取得したいならば、Gerv へメールを送ってください。そうしても 2 週間以内に回答が無い場合は、IRC へ照会を入れてください。Bugzilla の権限の取得要件も Gerv のページ で説明されています。

    Canconfirm 権限

    Canconfirm 権限によって、バクの確定ができるだけでなく、確定された状態 (NEW) でバグ報告を開始することが可能になります。

    確定されていないバグを確定する

    新しいバクを報告する

    上記の 2 つの手引きで説明されている振り分け作業を行なったバグは、NEW として報告するべきです。

    報告された公開バグは 2 ヶ月に一度は、すべて目を通して (すべての Bugzilla ページの最下部にある「My Bugs」のリンクを参照してください)、バグが引き続き存在しているかどうかテストしてください。

    Editbugs 権限

    canconfirm 権限に加えて、さらに強力な editbugs 権限によって、バクのほとんどの面を修正することも可能になります。従って権限を乱用しないようにしてください。

    バグを解決する

    一般規則として:

    • バクを解決する時は、新事実が発生した時参照できるように、CC を自分自身に送っておく。
    • バクを解決しないための条件は、バクを解決するための条件より必ず優先される。
    • バグを解決することに疑問がある時は、そのままにして置くこと!
    DUPLICATE としてバクを解決する

    DUPLICATE バグを選別するための手引き を参照してください。一般的に新規のバグは古いバグの DUPLICATE として扱われるべきですが、新しいバグの方が情報量が多い場合 (バグの記述がより明瞭、パッチがすでに添付されている、多くの人が CC している、等々) は例外です。

    WORKSFORME としてバグを解決する

    報告のあったハードウエアや OS で再現不可能であれば、WORKSFORME (WFM) としてバグを解決できます。

    WFM としてバクを解決するべきではないのは:

    • バグの報告者が別のハードウエアや OS を使っている場合。(例: Linux で発生するバグを、Windows で再現できない場合)
    • バグを再現した人たちがいる一方で、再現できない人たちもいる場合。

    一般的にバグを WFM として解決できるのは:

    • 3 人以上の人たちが類似または同様の設定でバグを再現できず、バグ報告者だけにバグがある場合。この場合すぐに WFM と決めるべきではなく、最初に報告者に詳細を確認してください。WFM とする際には、もし引き続きバグが最新のビルドで発生しているならば、バグ報告者にバグを再公開するように指示してください。
    • バグ報告の対象となっているビルドが、安定版 2 回以上古いリリースであり、現在のビルドでは再現できない場合。
    • バグ報告者が 1 ヶ月間質問に回答しておらず、現在のビルドでは再現できない場合。
    • バグ報告者がバグをもう見ることはないと言っており、バグが現在も発生していると報告する人が他にいない場合。
    INCOMPLETE としてバグを解決する

    The problem is vaguely described with no steps to reproduce, or is a support request. The reporter should be directed to the product's support page for help diagnosing the issue. If there are only a few comments in the bug, it may be reopened only if the original reporter provides more info, or confirms someone else's steps to reproduce. If the bug is long, when enough info is provided a new bug should be filed and the original bug marked as a duplicate of it.

    INVALID としてバグを解決する

    バグで記述される問題が Mozilla のバグでないことが明白であったり、問題が意図された動作であったりするならば、バグは INVALID として解決されるべきです。例外は私たちが対処する必要のある他のソフトウェアのバグです。この例外に含まれるバグは、モジュールオーナーやモジュールピア によってのみ INVALID とされるべきです。劣悪なコーディングや専有技術の使用の結果として Web サイトに発生する問題の結果の報告も同様に INVALID とされ、替わりに Tech Evangelism プロダクトへと移動されるべきです。

    FIXED としてバグを解決する

    Mozilla CVS コードレポジトリへのチェックインによってバグが修正されたならば、FIXED としてバグを解決してください。再現できなくなったバグは、ひとつのチェックインに関連付けられない場合、FIXED ではなく WORKSFORME として扱ってください。

    WONTFIX としてバグを解決する

    普通の振り分け担当者は、バグを WONTFIX とするべきではありません。WONTFIX として扱うかどうかの決定はモジュールオーナーやモジュールピアに任されています。

    バグを確認する

    バグが正しく解決されたことが判明したならば、バグを確認すべきです。バグを確認する際は、以下のことを忘れないでください。

    • DUPLICATE を確認することが一番易しい仕事なので、そこから着手してください。元のバグが解決されるまでは、DUPLICATE を確認することは一般的に不可能であることに留意してください。
    • 開発者か信頼されている QA 担当がバグを WONTFIXINVALID にしているならば、WONTFIXINVALID のバグを確認することは比較的容易です。それ以外の人が WONTFIXINVALID にしたバグは モジュールオーナーかモジュールピアが確認するべきです。もしくは、モジュールオーナーかモジュールピアが該当モジュールについて確認能力があるとして明確に指名した人間が確認するべきです。
    • FIXED バグを確認する前に、それらのバグが報告されたすべてのハードウエア や OS 上で確認できることを確かめてください。もしそれが不可能であれば、複数の人たちと協力してバグを確認するようにしてください。
    • WORKSFORME を確認するための明確な規則はありません。一般的にバグが数ヶ月間解決されていて解決方法について苦情が発生していないことを確かめるべきです。

    バグ情報項目を変更する

    要約

    現在の要約が不明確であったり、バグが含まれる問題を正確に説明していないならば、要約を変更すべきです。異なる問題を説明するバグへと変容させるために要約を変えてはいけません。この場合、元のバグを解決して別のバグを公開すべきです。

    OS とハードウェア

    影響を被るシステムが、OS やハードウエアの項目によって必ず正確に表示されるようにしてください。バグが Windows だけならば、影響を受ける最も古いオペレーテイングシステムへ項目を変更してください。バグが Linux と Windows に存在するなら、項目をハードウエア = PC と OS = ALL へ変更してください。Mac や DEC のような他のハードウエア・プラットフォームも影響を受けるならば、ハードウエアを ALL へ変更してください。

    重要度

    バグの様々な重要度の一覧については、説明 を参照してください。

    重要度を blocker としなければならない頻度はほとんどありません。というのは、Mozilla の開発を妨げるのは数十万のバグのうちのほんの一握りであり、そういうバグは普通すぐに修正されてしまうからです。その結果、数日 UNCONFIRMED であるバグは、blocker の重要度に格付けされるまでになりません。この規則の例外は、プラットフォームに固有であるかコンパイラに固有のバグです。基本的にビルドの生成や作動を妨げ、dogfood (BugzillaTinderboxLXR 等を使用できる) としての使用を妨げるものはすべて blocker です。

    クラッシュ、ハング、データ損失や重大なセキュリティ脆弱性 (任意コードのリモート実行等) に関するバグ報告の重要度は critical です。

    優先度とターゲットマイルストーン

    Bugzilla Etiquette に述べられていますが、ターゲットマイルストーンと優先度を変更してはいけません。これらの項目は開発者向けに存在します。過去のターゲットマイルストーンのバクも例外でありません。

    バグを再割り当てする

    バグが異なるプロダクトまたはコンポーネントに属しているならば、再割り当てされるべきです。バグを再割り当てする場合は、以下のことを留意してください。

    • コメントテキストボックス下の初期設定値のオーナーと QA コンタクトに再割り当てするラジオボタンにチェックを入れることを必ず忘れないでください。
    • Application SuiteThunderbirdFirefox のような Mozilla アプリケーションはプログラムコードのほとんどを占め、ネットワーク接続性 (FTP、HTTP、IMAP) および HTML 表示 を含めたすべてのバックエンドコードを占有しています。Thunderbird や Firefox のバグを Application Suite でもテストし、もしバグが Application Suite でも再現したなら、バグをコア・プロダクトのどれかに移動するようにしてください。
    • もしバグの所属先が不明の時は、触らないでください! 例えば、バグが JS エンジンのバグであることを熟知している場合以外は、JS エンジン・コンポーネントへの移動を行なってはいけません。そして、記述されている異常が DOM 問題であると知っているならば、バグを JS エンジンのまま放置しないでください。

    バグのフラグ

    Mozilla の ドライバー はリリースを阻害するバグを識別するためにフラグを使用します。阻害している状態のバクを命名するために blocking? フラグを使うだけで良いです。blocking- フラグと blocking+ フラグの使用は禁止されています。継続して乱用すると Bugzilla 権限が停止されることになります。

    一括変更

    一括変更 (二つ以上のバグを同時に変更すること) は推奨されません。慎んでください!

    原文書の情報

    • 著者: Simon Paquet
    • 貢献者: Andreas Kunz, Boris Zbarsky, Christian Biesinger, Daniel Wang, Fantasai, Ian Hickson, James Graham, and Michael Lefevre

    ドキュメントのタグと貢献者

    タグ: 
    Contributors to this page: Kohei, ethertank, Mgjbot
    最終更新者: ethertank,