2. XFS 維護者條目配置檔案¶
2.1. 概述¶
XFS 是 Linux 核心中一個著名的高效能檔案系統。 本專案的目標是提供和維護一個健壯且高效能的檔案系統。
補丁通常會被合併到相應 git 倉庫的 for-next 分支。經過一段測試期後，for-next 分支會被合併到 master 分支。
核心程式碼會被合併到 xfs-linux 樹 [0]。 使用者空間程式碼會被合併到 xfsprogs 樹 [1]。 測試用例會被合併到 xfstests 樹 [2]。 磁碟格式文件會被合併到 xfs-documentation 樹 [3]。
所有涉及 XFS 的補丁集 *必須* 將整個補丁抄送至郵件列表 linux-xfs@vger.kernel.org。
2.2. 角色¶
XFS 專案中有八個關鍵角色。一個人可以承擔多個角色，一個角色也可以由多個人擔任。建議承擔任何角色的人定期檢查自己和他人的倦怠情況。
外部貢獻者：傳送補丁但未定期參與 XFS 專案的任何人。這些人通常是在其他檔案系統或核心社群其他地方工作的人。
開發者：對 XFS 程式碼庫非常熟悉，可以編寫新程式碼、文件和測試的人。
通常可以在核心 MAINTAINERS 檔案中
C:條目中提到的 IRC 頻道中找到開發者。高階開發者：非常熟悉 XFS 程式碼庫的至少一部分和/或核心中其他子系統的開發者。這些人共同決定專案的長期目標，並朝著這個方向推動社群。他們應幫助確定每個釋出週期的開發和審查工作的優先順序。
高階開發者往往會更積極地參與 IRC 頻道。
審查者：讀取程式碼提交以決定的人（很可能也是開發者）
貢獻背後的想法是否合理？
這個想法是否符合專案的目標？
貢獻的設計是否正確？
貢獻是否已打磨？
貢獻是否可以有效地測試？
審查者應使用核心和 fstests MAINTAINERS 檔案中的
R:條目標識自己。測試負責人：此人負責設定專案的測試覆蓋率目標，與開發者協商以確定新功能的測試，並確保開發者和釋出管理者執行測試。
測試負責人應使用 fstests MAINTAINERS 檔案的 XFS 部分中的
M:條目標識自己。Bug 分類者：詳細檢查收到的錯誤報告，以確定應將報告轉發給誰的人。
Bug 分類者應使用核心 MAINTAINERS 檔案中的
B:條目標識自己。釋出管理者：此人將審查後的補丁集合併到整合分支中，在本地測試結果，將分支推送到公共 git 倉庫，並向上遊傳送拉取請求。不期望釋出管理者處理新功能補丁集。如果開發者和審查者在某些問題上未能達成決議，釋出管理者必須有能力進行干預，以嘗試推動決議。
釋出管理者應使用核心 MAINTAINERS 檔案中的
M:條目標識自己。社群管理者：當郵件列表討論不足以做出集體決策時，此人召集並主持儘可能多的 XFS 參與者的會議。他們還可以充當贊助 XFS 任何部分工作的組織管理者之間的聯絡人。
LTS 維護者：此人將來自上游的錯誤修復向後移植並測試到 LTS 核心。在任何給定時間，通常有六個獨立的 LTS 樹。
給定 LTS 版本的維護者應使用該 LTS 樹的 MAINTAINERS 檔案中的
M:條目標識自己。未維護的 LTS 核心應在該檔案中標記為S: Orphan狀態。
2.3. 提交清單附錄¶
提交到 XFS 時，請遵循以下附加規則
僅影響檔案系統本身的補丁應基於最新的 -rc 或 for-next 分支。這些補丁將合併回 for-next 分支。
涉及其他子系統的補丁的作者需要與 XFS 和相關子系統的維護者協調，以決定如何進行合併。
任何更改 XFS 的補丁集都應將其整個補丁抄送至 linux-xfs。不要傳送部分補丁集；這會不必要地增加分析更改的更廣泛上下文的難度。
任何對核心進行更改，並且使用者空間實用程式有相應更改的人，都應在核心補丁集之後立即將使用者空間更改作為單獨的補丁集傳送。
預期錯誤修復補丁的作者使用 fstests [2] 對補丁執行 A/B 測試，以確定沒有迴歸。在可能的情況下，應為 fstests 編寫新的迴歸測試用例。
新功能補丁集的作者必須確保 fstests 具有適用於新功能的適當的功能和輸入角落案例測試用例。
在實現新功能時，強烈建議開發者編寫一份設計文件來回答以下問題
什麼問題正在嘗試解決？
誰將從該解決方案中受益，以及他們將在哪裡訪問它？
如何這個新功能將如何工作？這應涉及主要的資料結構和演算法，以比程式碼註釋更高的級別支援解決方案。
構建新功能需要什麼使用者空間介面？
如何將對這項工作進行測試，以確保它解決了設計文件中提出的問題，而不會引起新的問題？
設計文件應提交在核心文件目錄中。如果社群已經非常瞭解該功能，則可以省略該文件。
新測試的補丁集應在核心和使用者空間程式碼補丁集之後立即作為單獨的補丁集提交。
對 XFS 磁碟格式的更改必須在磁碟格式文件 [3] 中描述，並在 fstests 補丁集之後作為補丁集提交。
實現錯誤修復和進一步程式碼清理的補丁集應將錯誤修復放在序列的開頭，以方便向後移植。
2.4. 關鍵釋出週期日期¶
錯誤修復可以隨時傳送，但釋出管理者可以決定在下一個合併視窗臨近時推遲補丁。
針對下一個合併視窗的程式碼提交應在 -rc1 和 -rc6 之間傳送。這使社群有時間審查更改、提出其他更改，並使作者可以重新測試這些更改。
還需要更改 fs/iomap 並針對下一個合併視窗的程式碼提交應在 -rc1 和 -rc4 之間傳送。這使更廣泛的核心社群有足夠的時間來測試基礎設施更改。
2.5. 審查節奏¶
通常，請至少等待一週再 ping 以獲得反饋。要查詢審查者，請查閱 MAINTAINERS 檔案，或詢問已獲得 XFS 更改的 Reviewed-by 標籤的開發者，請他們檢視並提供他們的意見。