バグはどのように分類され、バグのライフサイクルはどのようになりますか?


12

Ubuntuのバグはどのように分類され、バグのライフサイクルは何ですか?

また、「各バグの「ステータス」は何を意味し、どのように決定されるのか」

回答:


18

Ubuntuのすべてのバグにはライフサイクルがあります。また、それぞれのライフサイクルが何であるかを説明するのに役立つ「ステータス」があります。Ubuntuでは、ライフサイクルが継続するたびに各バグにさまざまなステータスが設定されます。

これはすべて、トリアージガイドで非常に詳細に文書化されていますが、(現時点では、このプロセスをテキストで書くのに膨大な時間はありませんが、後で説明します)が提供する「フローチャート」を投稿しますこのためのバグチーム(フローチャートのソースについては、ここをクリックしてください)。それぞれの状態(その間)はBugs / Status BugSquad Documentationで説明できますが、ここでもそれらを文書化しました。

(以下の情報は、Wikiのドキュメントでは古くなっている可能性があります。最新の情報については、Wikiを参照してください。)


以下は、バグの各ステータスインジケータの説明です。

  • 新着:
    • バグはこのステータスで送信されます
    • 彼らは時々情報失い
    • それらはすべてトリアージされていないはずです
  • 不完全な:
    • レポーターに質問する必要がある場合は、バグを未完了に設定してください
    • 提出者にコメントで必要な情報を提供するように依頼し、バグレポートを自分でサブスクライブして、バグの更新を電子メールで受け取るようにしてください。
    • 一部のバグは、提出者によって応答されません(「元のポスター」または「OP」とも呼ばれます)。これらのバグは、不完全に設定された日から数えて、60日間でLaunchpadによって自動的に期限切れになります。それらに対処する必要はありません(実際、バグを変更すると有効期限が再開します)。これはUbuntuプロジェクト(つまり、名前に「(Ubuntu)」が含まれるバグタスク)に適用されることに注意してください。他のプロジェクトでは、自動的に不完全なバグ有効期限が設定されている場合と設定されていない場合があります。
    • あなたを含む誰かがバグについてコメントすると、60日間の有効期限がリセットされます。
  • 意見:
    • 「意見」というステータスは、特定のバグに関して意見の相違があり、人々が自由に議論を続けることができることを意味しますが、プロジェクトまたはパッケージのメンテナーは他の作業に移行する必要があり、問題を解決することを検討しています。バグはクローズとしてマークできるので、開発者はバグに時間を浪費しませんが、議論はまだ進行中です。
    • このステータス「意見」は実験とみなされ、綿密に監視されます。
  • 無効:
    • このステータスは、バグレポートに適切な情報が含まれていない場合に使用します。この情報は、報告者にとって解決された場合でもバグかどうかを判断するために使用します。
    • これは、報告された問題がまったくバグではなく、たとえばユーザーエラーの場合にも使用する必要があります。
    • 無効とマークされたバグがデフォルトの検索で表示されなくなるため、控えめに使用する必要があります
    • バグを無効にする前に、必ずトリプルチェックしてください
  • 期限切れ:
    • このステータスは「無効」に似ていますが、あまりにも長い間不完全であったバグ専用です。(上記を参照。)
    • このステータスは、launchpadlibまたは電子メールインターフェイスを使用してのみ設定できます。
    • 無効なバグと同様に、期限切れのバグはデフォルトの検索には表示されません。
  • 確認済み
    • 別のレポーターが同じバグを経験しました。これは、重複したバグまたはバグコメントの形で発生する可能性があります
    • 確認されたバグには、元のレポーター以外の誰かからの確認が必要です
    • これにより、バグが一般的にUbuntuに適用され、レポーターのシステムの問題ではないことが保証されます。したがって、...
    • 自分のバグを確認しないでください!
  • トリアージ:
    • UbuntuBugControlのメンバーは、レポートが開発者が修正作業を開始できるほど詳細に本物のバグを記述していると考えています。(以下のヒントも参照)
    • これは、開発者が確認する必要があると確信しており、十分な情報がある場合に使用します
    • 要件ではありませんが、アップストリーム転送が発生する前に、バグのUbuntuタスクステータスがトリアージされます
    • Linux Triagedのバグは、バグがアップストリームメインラインカーネルでテストされたことを意味します
  • 進行中:
    • 場合あなたはバグの修正に取り組んでいる人々は何が起こっているか知っているので、進行中に設定します
    • 進行中のバグは、それらに取り組んでいる人に割り当てられるべきです
  • コミットされた修正:
    • Ubuntuのバグタスク:変更は保留中であり、すぐにアップロードされます(BugzillaのPENDINGUPLOADの内容です)
    • Fix Committedは、更新パッケージが-proposedリポジトリに存在する場合、つまりhardy-proposedの場合にも使用されます
    • Fix Committedは、パッチがバグに添付されている場合には使用されません。
    • 上流のバグタスク:修正はCVS / SVN / bzrにあるか、どこかにコミットされています
  • 修正リリース:
    • Ubuntuバグタスク:公式のUbuntuリポジトリに修正がアップロードされました
    • NBこれには、-proposed、つまりhardy-proposedは含まれません
    • チェンジログをコメントとして追加することをtしないでください。そうすれば、どのパッケージのバージョンでバグが修正されたかを知ることができます
    • 現在の開発リリースでバグが修正されている場合、修正リリースです。安定版リリースでもバグを修正する必要がある場合は、「リリースするターゲット」リンクを使用して、そのリリースにバグを指定してください。
    • 上流のバグタスク:リリースtarballが発表され、公開されています
  • 修正しない:
    • このステータスは、バグ修正が物議を醸す場合に時々使用されます
    • これは、特定のリリースでは修正されないが、後で修正される可能性があるリリースターゲットのバグに最もよく使用されます。
    • 開発者が実装したくない機能要求にも使用できます

(ここでの書式設定はより制限されているため、書式設定はウィキとは少し異なります)


関連する質問と回答:
重要度:Ubuntuバグの重要度はどのように決定されますか


フローチャートは、削除された-私たちは、私は...と思ういくつかの点でそれらを再構築する必要がある
トーマス・ウォード
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.