LLVM 社群支援政策¶
作為一個編譯基礎設施，LLVM 有多種類型的使用者，包括下游和上游，他們使用其專案、工具和函式庫的各種組合。
其中核心部分包含編譯器（前端/中端/後端）、執行時期函式庫（RT、C++、OpenMP 等）以及相關工具（除錯器、連結器、物件檔案操作等）的實作。這些組件存在於我們支援的架構和作業系統的公開發布版本中，整個社群都必須維護和關心。
然而，在主要儲存庫中還有其他組件，它們要么是為了滿足 LLVM 的特定子社群（上游或下游），要么是幫助社群的部分成員將 LLVM 整合到他們自己的開發工具或外部專案中。主要儲存庫的這些部分並不總是像核心部分那樣經過嚴格的測試，也不會與我們的公開上游發布版本一起驗證和發布。
即使不是專案的核心部分，我們也有足夠的子社群需要這些變更，並且有足夠的重疊，因此將它們放在主要儲存庫中對於最小化所有需要它們的外部儲存庫中這些變更的重複是有益的。
但是，如此多樣化的生態系統的維護成本並不低，因此我們將支援級別分為兩個層級：核心和周邊，具有兩種不同的影響和責任級別。這些層級僅指主要儲存庫（llvm-project），而不包括我們 git 專案中的其他儲存庫，除非另有明確說明。
無論層級如何，所有程式碼都必須遵守現有的品質、審查、樣式等政策。
核心層級¶
核心層級包含主要儲存庫中所有已投入生產、經過積極測試並按常規排程發布的程式碼，包括核心 LLVM API 和基礎設施、前端/中端/後端、執行時期函式庫、工具等。
關心核心層級是每位 LLVM 開發人員的責任，無論他們的工作應用於何處。
涵蓋範圍¶
- 核心層級由以下部分組成
官方發布版本和建置機器人中存在的核心程式碼（
llvm-project）：編譯器、除錯器、連結器、函式庫等，包括基礎設施程式碼（table-gen、lit、file-check、單元測試等）。建立發布版本和建置機器人的建置基礎設施（CMake、腳本）。
Phabricator 和 建置機器人 基礎設施。
要求¶
- 此層級中的程式碼必須
保持官方建置機器人綠色，並將故障警告以電子郵件發送給所有受影響的開發人員。這些問題必須盡快修復，或者必須根據審查政策還原補丁。
核心層級組件的位元腐爛將導致該組件降級為周邊層級或被移除。子社群可以透過及時修復所有提出的問題來避免這種情況。
周邊層級¶
周邊層級包含 LLVM 中滿足特定子社群需求的部分，這些部分通常不會直接影響核心組件。
這包括實驗性後端、預設禁用的選項和同一儲存庫中的替代路徑（正在進行中的替換），以及將 LLVM 開發與本地實踐整合的獨立努力。
每個子社群都有責任關心自己的部分以及其與核心層級和其他周邊部分的交叉部分。
- 此類別中主要有三組程式碼
透過 實驗性 路線圖或類似努力進入 LLVM 的程式碼。
透過棄用、替換或位元腐爛而退出 LLVM 的程式碼，如果關心它的子社群無法維護它，則將被移除。
不打算放入 LLVM 核心並且可以與核心層級（以及周邊層級中的其他程式碼）長期共存，而不會引起故障或干擾的程式碼。
涵蓋範圍¶
- 周邊層級由以下部分組成
尚未預設啟用的實驗性目標和選項。
未發布或定期測試的主要儲存庫專案。
上游驗證中未使用的舊版工具和腳本。
替代建置系統（例如 GN、Bazel）和相關基礎設施。
工具支援（例如 gdb 腳本、編輯器配置、輔助腳本）。
要求¶
- 此層級中的程式碼必須
對於駐留在主要儲存庫中具有明確的好處，以滿足活躍的子社群（上游或下游）的需求。
由該子社群積極維護，並及時解決其問題。
- 此層級中的程式碼不得
破壞或使核心層級程式碼或基礎設施失效。如果意外發生這種情況，還原功能並離線處理問題是唯一可接受的行動方案。
對核心層級程式碼的開發產生負面影響，相關子社群負責進行變更以解決特定問題。
對其他周邊層級程式碼產生負面影響，相關子社群負責解決問題，同時仍需確保解決方案不會破壞或使核心層級失效。
由於周邊組件的特性，將次優的實作策略強加於核心層級組件。
具有向所有開發人員發送有關其故障的垃圾郵件的建置基礎設施。
陷入失修狀態。這反映了缺乏活躍的子社群，並將導致移除。
- 此層級中的程式碼應
在有意義的情況下，擁有基礎設施進行測試，並且沒有警告或通知包含在子社群內。
支援和測試應隨著組件的複雜性和彈性而擴展，對於簡單且優雅降級的組件（例如編輯器綁定），其標準遠低於必須保持 HEAD 最新狀態的複雜組件（例如實驗性後端或替代建置系統）。
擁有一份文件，明確說明實作狀態、可用的支援級別、子社群是誰，以及（如果適用）納入核心層級的路線圖。
限制在特定目錄或具有一致的模式（例如，唯一的文件後綴），以便在必要時輕鬆移除。
納入政策¶
要新增新的周邊組件，請向適當的開發人員列表發送 RFC，提議新增該組件並解釋它將如何滿足上面列出的支援要求。不同類型的組件可能需要不同程度的詳細資訊。如有疑問，請諮詢社群以了解最佳方法。
納入必須在社群的 RFC 中達成共識，並且相應審查（由社群的多個成員進行）的批准是正式的接受通知。
合併後，通常會有一段過渡期，在此期間會發現並修復現有建置機器人上的初期問題。如果這些問題無法立即修復，則子社群負責追蹤和還原所有相關補丁，並重試納入審查。
一旦組件在樹狀結構中穩定，它必須遵循此政策，並且以下棄用規則適用。
由於納入的不確定性，建議不要在發布分支附近新增組件。時間將取決於組件的大小和複雜性，因此強烈建議在 RFC 和審查中新增發布和測試管理員。
棄用政策¶
LLVM 程式碼庫中有許多檔案未被積極維護。但並非所有這些檔案都阻礙了專案的開發，因此它仍然保留在儲存庫中，並假設它可能仍然對下游使用者有用。
為了使程式碼保留在儲存庫中，其存在不得對維護其他組件（核心或周邊）造成不必要的負擔。
警告¶
可能會觸發棄用請求的多種類型問題，包括（但不限於）
組件中的變更持續破壞專案的其他區域。
組件長時間（數週或更長時間）損壞。
明顯優越的替代方案正在使用中，並且維護起來很痛苦。
建置和測試更困難/花費更長時間，增加了維護成本，超過了感知到的好處。
如果維護成本高於大多數開發人員可以接受的程度，則表示要么子社群太小（額外成本應在本地支付），要么不夠活躍（問題不會很快修復）。在任何一種情況下，移除此類有問題的組件都是合理的。
移除步驟¶
無論移除的需求多麼明確，我們都應採取漸進式方法來棄用程式碼，尤其是在仍然有子社群關心它的情況下。從這個意義上說，在採取一系列步驟之前，程式碼永遠不會被完全移除。
- 最少應包含以下步驟
應向 Discourse 論壇（在適當的類別下）提出移除/停用提案，並明確說明維護成本和替代方案（如果適用）。
列表上必須有足夠的共識認為移除是合理的，並且沒有來自子社群的待決提案來解決這種情況。
必須在相同的列表上發布移除公告，並為下游使用者提供充足的時間來對其本地基礎設施採取行動。時間將取決於要移除的內容。
如果要移除腳本或文件，它們始終可以從以前的版本中拉取，並且可以在幾天內移除。
如果要移除整個目標，我們需要先公開宣布，並可能在一個版本中標記為已棄用，僅在下一個版本中移除。
其他一切都將介於這兩個極端之間。
移除由提案者或過去維護它的子社群進行，並在同一個提交中以原子方式進行替換和安排。
如果由於子社群承諾將處理受影響的程式碼而延遲了移除提案，則子社群將有時間修復所有問題（取決於每種情況，如上所述），如果這些問題未及時修復，則應提出後續的移除請求，並且社群可以選擇在不進一步嘗試修復的情況下彈出組件。
恢復¶
如果組件從 LLVM 中移除，則稍後可以請求包含修改後的版本，並提供證據表明所有問題都已修復，並且有一個明確的子社群將維護它。
因此，此類子社群的壓力將更大，以將整體維護成本保持在最低限度，並且需要展示步驟來減輕所有被列為原始移除原因的問題。
如果再次失敗，將再次成為移除的候選者。