LLVMコミュニティサポートポリシー¶
コンパイレーションインフラストラクチャとして、LLVMには、そのプロジェクト、ツール、ライブラリのさまざまな組み合わせを使用する、ダウンストリームとアップストリームの両方の複数のタイプのユーザーがいます。
その中心となる部分は、コンパイラ（フロント/ミドル/バックエンド）、ランタイムライブラリ（RT、C ++、OpenMPなど）、および関連ツール（デバッガ、リンカ、オブジェクトファイル操作など）の実装を包含しています。これらのコンポーネントは、サポートされているアーキテクチャとオペレーティングシステムのパブリックリリースに存在し、コミュニティ全体が保守し、注意を払う必要があります。
ただし、メインリポジトリ内には、LLVMの特定のサブコミュニティ（アップストリームまたはダウンストリーム）に対応するか、コミュニティの一部がLLVMを独自の開発ツールまたは外部プロジェクトに統合するのに役立つ他のコンポーネントもあります。メインリポジトリのこれらの部分は、常にコア部分のような厳密なテストがあるわけではなく、パブリックアップストリームリリースで検証および出荷されることもありません。
プロジェクトのコア部分ではないとしても、これらの変更を必要とする十分な重複を持つサブコミュニティが十分に存在するため、メインリポジトリに含めることで、それらを必要とするすべての外部リポジトリでのこれらの変更の繰り返しを最小限に抑えるのに役立ちます。
ただし、そのような多様なエコシステムの維持コストは自明ではないため、サポートレベルをコアと周辺の2つの階層に分け、影響と責任のレベルを2つに分けています。これらの階層は、明示的に記載がない限り、メインリポジトリ（llvm-project）のみを指し、gitプロジェクトの他のリポジトリは指しません。
階層に関係なく、すべてのコードは品質、レビュー、スタイルなどに関する既存のポリシーに従う必要があります。
コア階層¶
コア階層は、本番環境で使用され、定期的にテストされ、定期的なスケジュールでリリースされるメインリポジトリ内のすべてのコードを包含します。これには、コアLLVM APIとインフラストラクチャ、フロント/ミドル/バックエンド、ランタイムライブラリ、ツールなどが含まれます。
作業がどこに適用されるかに関係なく、コア階層を管理するのはすべての LLVM開発者の責任です。
対象範囲¶
- コア階層は以下で構成されます。
公式リリースおよびビルドボットに存在するコアコード（
llvm-project）：コンパイラ、デバッガ、リンカ、ライブラリなど、インフラストラクチャコード（table-gen、lit、file-check、ユニットテストなど）を含む。リリースおよびビルドボットを作成するビルドインフラストラクチャ（CMake、スクリプト）。
Phabricator および buildbot インフラストラクチャ。
要件¶
- この階層のコードは、以下を満たす必要があります。
公式のビルドボットをグリーンに保ち、破損に関する警告は影響を受けるすべての開発者にメールで送信されること。レビューポリシーに従い、それらはできるだけ早く修正するか、パッチを元に戻す必要があります。
コア階層のコンポーネントのビット腐敗は、そのコンポーネントが周辺階層に格下げされるか、削除されることにつながります。サブコミュニティは、発生したすべての問題をタイムリーに修正することで、これを回避できます。
周辺階層¶
周辺階層は、特定のサブコミュニティに対応し、通常はコアコンポーネントに直接影響を与えないLLVMの部分を包含します。
これには、実験的なバックエンド、デフォルトで無効になっているオプション、および同じリポジトリ内の代替パス（進行中の代替品）と、LLVM開発をローカルプラクティスと統合するための個別の取り組みが含まれます。
各サブコミュニティは、自分たちの部分と、コア階層および他の周辺部分との交差に関心を持つ責任があります。
- このカテゴリに該当するコードには、主に3つのグループがあります。
実験的なロードマップまたは同様の取り組みを通じて、LLVMに組み込まれようとしているコード。
非推奨、置換、またはビット腐敗を介して、LLVMから出て行こうとしており、それを気にするサブコミュニティがそれを維持できない場合は削除されるコード。
LLVMコアに含まれることを意図しておらず、破損や混乱を引き起こすことなく、コア階層（および周辺階層の他の階層）のコードと長期的に共存できるコード。
対象範囲¶
- 周辺階層は以下で構成されます。
まだデフォルトで有効になっていない実験的なターゲットとオプション。
リリースまたは定期的にテストされていないメインリポジトリプロジェクト。
アップストリーム検証で使用されていないレガシーツールとスクリプト。
代替ビルドシステム（例：GN、Bazel）および関連インフラストラクチャ。
ツールサポート（例：gdbスクリプト、エディター構成、ヘルパースクリプト）。
要件¶
- この階層のコードは、以下を満たす必要があります。
メインリポジトリに存在するための明確な利点があり、アクティブなサブコミュニティ（アップストリームまたはダウンストリーム）に対応していること。
そのようなサブコミュニティによって積極的に保守され、その問題がタイムリーに対処されること。
- この階層のコードは、次のないこと。
コア階層のコードまたはインフラストラクチャを破損または無効にすること。それが誤って発生した場合、機能を元に戻し、オフラインで問題を解決することが唯一の容認できる行動です。
特定の懸念に対処するために変更を加える責任を負うサブコミュニティが関与する、コア階層コードの開発に悪影響を与えること。
問題を解決するタスクを負ったサブコミュニティが関与し、ソリューションがコア階層を破損または無効にしないことを引き続き確認して、他の周辺階層コードに悪影響を与えること。
周辺コンポーネントの特異性の結果として、コア階層コンポーネントに最適ではない実装戦略を課すこと。
破損についてすべての開発者にスパムを送信するビルドインフラストラクチャを持つこと。
荒廃に陥ること。これはアクティブなサブコミュニティの欠如を反映しており、削除につながります。
- この階層のコードは、以下を満たす必要があります。
サブコミュニティ内で警告や通知がない場合は、意味のある場合にテストするインフラストラクチャがあること。
コンポーネントの複雑さと回復力に合わせてスケールするサポートとテストがあること。シンプルな、適切に劣化するコンポーネント（エディターバインディングなど）のバーは、HEADを維持する必要がある複雑なコンポーネント（実験的なバックエンドや代替ビルドシステムなど）よりもはるかに低いこと。
実装のステータス、利用可能なサポートレベル、サブコミュニティが誰であるか、および該当する場合は、コア階層に含めるためのロードマップを明確にするドキュメントがあること。
必要に応じて削除を容易にするために、特定のディレクトリに制限するか、一貫したパターン（例：一意のファイルサフィックス）を持つこと。
包含ポリシー¶
新しい周辺コンポーネントを追加するには、適切な開発者リストにRFCを送信して、その追加を提案し、上記にリストされたサポート要件をどのように満たすかを説明します。コンポーネントのタイプが異なれば、異なるレベルの詳細が必要になる可能性があります。不明な場合は、コミュニティに最適なアプローチを尋ねてください。
包含は、コミュニティによるRFCで合意に達する必要があり、対応するレビュー（コミュニティの複数のメンバーによる）の承認は、公式の承認メモです。
マージ後、既存のビルドボットで歯ぎしり問題が発見されて修正される移行期間があることがよくあります。それらをすぐに修正できない場合、サブコミュニティは、関連するすべてのパッチを追跡して元に戻し、包含レビューを再試行する責任があります。
コンポーネントがツリー内で安定したら、このポリシーに従う必要があり、以下の非推奨ルールが適用されます。
包含の性質が不確実であるため、新しいコンポーネントをリリースブランチの近くに追加しないことをお勧めします。時間はコンポーネントのサイズと複雑さによって異なるため、RFCとレビューにリリースおよびテストマネージャーを追加することを強くお勧めします。
非推奨ポリシー¶
LLVMコードベースには、積極的にメンテナンスされていない多くのファイルがあります。しかし、これらのファイルのすべてがプロジェクトの開発を妨げているわけではないため、ダウンストリームユーザーにとってまだ役立つ可能性があるという前提で、リポジトリに残っています。
コードがリポジトリに残るためには、その存在が他のコンポーネント（コアまたは周辺）の維持に過度の負担をかけることはありません。
警告¶
非推奨のリクエストをトリガーする可能性のある問題には、以下を含む（ただし、これらに限定されない）複数のタイプがあります。
コンポーネントの変更が一貫してプロジェクトの他の領域を壊す。
コンポーネントが長期間（数週間以上）壊れたままになる。
明らかに優れた代替案が使用されており、メンテナンスが困難である。
ビルドとテストがより困難/時間がかかり、メンテナンスコストが増加し、認識されている利点を上回る。
メンテナンスコストがほとんどの開発者によって許容できるよりも高い場合、それはサブコミュニティが小さすぎる（追加コストはローカルで支払われるべきである）か、十分な活動がない（問題はすぐに修正されない）かのいずれかを意味します。いずれの場合も、このような問題のあるコンポーネントの削除は正当化されます。
削除の手順¶
削除の必要性がどれほど明確であっても、特にそれを気にしているサブコミュニティがまだ存在する場合は、コードの非推奨化には段階的なアプローチを取るべきです。その意味で、コードは一連のステップを踏まずに完全に削除されることはありません。
- 最低限必要なステップは以下の通りです。
削除/非アクティブ化の提案は、（適切なカテゴリの）Discourseフォーラムで行う必要があり、維持コストや、該当する場合は代替案を明確に述べる必要があります。
削除が正当であるという点で、リストに十分なコンセンサスがあり、サブコミュニティからの状況を修正するための提案が保留されていない必要があります。
削除のアナウンスは、同じリストで行う必要があり、下流のユーザーがローカルインフラストラクチャでアクションを起こすための十分な時間が必要です。時間は、削除されるものによって異なります。
スクリプトまたはドキュメントが削除される場合、それらは常に以前のリビジョンから取得でき、数日以内に削除できます。
ターゲット全体が削除される場合、最初に公に発表し、場合によってはあるリリースで非推奨としてマークし、次のリリースでのみ削除する必要があります。
それ以外のものは、これら2つの極端なケースの中間に位置します。
削除は、提案者またはそれを維持していたサブコミュニティによって行われ、代替案と調整は同じコミットでアトミックに行われます。
削除の提案が、サブコミュニティが影響を受けるコードの面倒を見るという約束によって遅れた場合、サブコミュニティはすべての問題を修正する時間（上記のように、ケースによって異なります）が与えられ、それらが時間内に修正されない場合は、削除の再要求が行われ、コミュニティは修正をさらに試みることなくコンポーネントを削除することを選択できます。
復元¶
コンポーネントがLLVMから削除された場合、後日、すべての問題が修正され、それを維持する明確なサブコミュニティが存在するという証拠とともに、変更されたバージョンの包含を要求する可能性があります。
その結果、そのようなサブコミュニティへの圧力は、全体的な維持コストを最小限に抑えるために高くなり、元の削除の理由として挙げられたすべての問題を軽減するための措置を示す必要があります。
再び失敗すると、再び削除の候補になります。