維護者入門檔案¶
維護者入門檔案是對頂級過程文件（提交補丁、提交驅動程式...）的補充，其中包含了子系統/裝置驅動程式的本地慣例以及補丁提交生命週期的詳細資訊。貢獻者可以使用此文件來設定他們的預期並避免常見錯誤；維護者可以使用這些檔案來跨子系統查詢統一常見實踐的機會。
概述¶
介紹子系統如何運作。雖然 MAINTAINERS 檔案告訴貢獻者應將補丁傳送到哪些檔案，但它不傳達其他有助於開發的子系統本地基礎設施和機制。
需要考慮的示例問題
當補丁應用於本地樹或合併到上游時，是否有通知？
子系統是否有 patchwork 例項？patchwork 狀態變化是否會通知？
是否有任何監控列表的機器人或 CI 基礎設施，或者子系統用於控制接受的自動化測試反饋？
哪些 Git 分支會被拉入 -next？
貢獻者應該針對哪個分支提交？
連結到任何其他維護者入門檔案？例如，裝置驅動程式可能會指向其父子系統的入門檔案。這讓貢獻者瞭解維護者在提交鏈中可能對其他維護者承擔的義務。
提交清單附錄¶
除了常見的“提交清單”之外，列出補丁被維護者視為足夠健康所需的強制性和建議性標準。例如：“透過 checkpatch.pl 檢查，無錯誤或警告。透過 $URI 處詳述的單元測試。”
提交清單附錄還可以包含有關相關硬體規範狀態的詳細資訊。例如，子系統是否要求在考慮補丁之前，已有特定修訂版本的已釋出規範。
關鍵週期日期¶
提交者常見的誤解之一是，補丁可以在合併視窗關閉之前的任何時間傳送，並且仍然可以被考慮用於下一個 -rc1。實際情況是，大多數補丁需要在合併視窗開啟之前提前在 linux-next 中充分醞釀。為提交者明確關鍵日期（以 -rc 釋出周為準），補丁何時可能被考慮合併，以及何時需要等待下一個 -rc。最低限度：
新功能提交的最後 -rc：針對下一個合併視窗的新功能提交，應在此時間點之前首次釋出以供考慮。在此時間點之後提交的補丁應明確說明它們的目標是 NEXT+1 合併視窗，或者應提供充分的理由說明為何應加快處理。一般指導原則是與貢獻者設定預期，即新功能提交應在 -rc5 之前出現。
合併功能的最後 -rc：合併決策的截止日期。告知貢獻者何時尚未應用補丁集需要等待 NEXT+1 合併視窗。當然，沒有任何義務必須接受任何給定的補丁集，但如果審查在此時間點尚未結束，則預期貢獻者應等待併為下一個合併視窗重新提交。
可選
開發基線分支（在概述部分列出）應被視為可接受新提交的第一個 -rc 版本。
審查節奏¶
貢獻者最大的焦慮來源之一是，在補丁集釋出後未收到任何反饋時，多久應該催促。除了指定重新提交前應等待多久之外，本節還可以指出首選的更新方式，例如重新發送完整系列，或私下發送提醒郵件。本節還可以列出此程式碼區域的審查工作方式，以及不直接來自維護者的獲取反饋的方法。
現有檔案¶
目前，現有的維護者檔案列在此處；我們可能希望在不久的將來做些不同的事情。