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