LLVMバグライフサイクル¶
はじめに - バグレポートの取り扱いにおける一貫性の実現¶
報告されたバグが、報告されてから、作業対象となり、最終的にクローズされるまでの過程において、基本的な一貫性を実現することを目指しています。この一貫性は、報告者、開発者、その他の人々が、特定のバグの状態が実際に何を意味し、次に何が起こるかをより良く理解するのに役立ちます。
同時に、LLVMバグ追跡システムにおけるバグのライフサイクルを過度に具体化しないことを目指しています。全体的な目標は、バグレポートの操作と理解を容易にすることであるためです。
ここでドキュメント化されているライフサイクルの主な部分は以下のとおりです。
さらに、使用するラベルなど、バグトラッカーのメタデータの一部をメンテナンスする必要があります。詳細については、以下を参照してください。
バグの報告¶
優れたバグレポートの提出方法の詳細については、LLVMバグレポートの提出方法を参照してください。
ラベルをバグに適用して、バグがプロジェクトのどの部分に関連するかを示すラベルなど、バグを見つけやすくするための追加情報を提供できます。
バグのトリアージ¶
confirmedラベルが付いていないオープンなバグは、トリアージが必要なバグです。トリアージが完了したら、問題をクローズする場合を除き、レポートを分類するのに役立つ他のラベルと一緒にconfirmedラベルを追加する必要があります。
バグをトリアージする目的は、新しく報告されたバグが、適切で実行可能な状態になるようにすることです。トリアージ中に次の質問に答えるようにしてください。
報告された動作は実際に間違っていますか？
例えば、誤コンパイルの例は未定義の動作に依存していますか？
レポートの詳細からバグを再現できますか？
できない場合、再現できない合理的な説明はありますか？
既に報告されたバグに関連していますか？
以下のフィールドは正しく入力されていますか？
タイトル
説明
ラベル
可能であれば、ツール（
clang、clang-format、clang-tidyなど）またはコンポーネント（backend:<name>、compiler-rt:<name>、clang:<name>など）など、バグを分類するための適切なラベルを追加してください。問題がCまたはC++標準の特定のリビジョンに関連する場合は、適切な言語標準ラベル（
c++20、c99など）を追加してください。一般的なラベルと特定のラベルの両方を使用しないでください。例えば、
c++17とラベル付けされたバグにはc++も含まれていてはならず、clang:codegenとラベル付けされたバグにはclangも含まれていてはなりません。LLVMを初めて使用する人が修正するのに適したバグであると思われる場合は、
good first issueラベルを追加してください。このラベルは、新しい貢献者のためのランディングページに供給されます。ラベルが何に使用されるかを確信できない場合は、ラベルのドキュメントを参照してください。
バグ修正への積極的な取り組み¶
バグの修正に積極的に取り組んでいる場合は、自分自身にバグを割り当て、作業を完了したら割り当てを解除することを忘れないでください。バグの割り当てを解除するには、Assigneesフィールドから人を削除します。
バグの解決/クローズ¶
バグの解決は良いことです！解決の理由を適切に記録してください。解決の理由の例を以下に示します。
問題が特定のコミットによって解決された場合は、どのコミットで修正されたかを簡単にコメントして問題をクローズします。自分で修正を作成する場合、gitコミットメッセージには、
Fixes #<issue number>というフレーズを単独の行に含めることができます。GitHubは、このようなコミットメッセージを認識し、指定された問題を自動的にクローズし、コミットへの参照を追加します。報告された動作がバグでない場合は、バグではないと考える理由を説明するコメントを追加し、
invalidタグを追加して、問題をクローズすることが適切です。バグが別の問題と重複する場合は、重複している問題を示すコメントとともに、
duplicateラベルを追加して、重複としてクローズします。問題を修正しない正当な理由（困難、ABI、未解決の研究課題など）がある場合は、
wontfixラベルと、変更が期待されない理由を説明するコメントを追加します。特定のバグが適用できないか、または廃止されていると考えるための具体的かつ妥当な理由がある場合。例としては、報告された問題を明確に理解するのに十分な情報が含まれていない（再現不可能など）オープンなバグが挙げられます。このようなバグをクローズし、
worksformeラベルを追加し、報告者がまだ再現可能な場合は、より多くの情報を提供してバグを再オープンするように促すコメントを残すことは問題ありません。
メタデータのメンテナンス¶
プロジェクトへの書き込みアクセス権を持つプロジェクトメンバーは、新しいラベルを作成できますが、ラベルの急増を制御し、単回使用ラベルを避けたいため、アドホックラベルを追加することは推奨しません。新しいラベルを追加したい場合は、問題ラベルの作成を依頼する問題をオープンし、その問題にinfrastructureラベルを追加してください。リクエストには、ラベルの目的の説明を含める必要があります。または、LLVM Discordの#infrastructureチャネルでラベルの作成を依頼することもできます。