2. 向 bcachefs 提交補丁¶
以下是向 bcachefs 子系統提交補丁的建議。
2.1. 提交清單¶
補丁在提交之前必須經過測試，可以使用 xfstests 套件 [0]，或者 ktest 中的完整 bcachefs 測試套件 [1]，具體取決於所涉及的內容。 請注意，ktest 包裝了 xfstests，對於大多數使用者來說，這將是一個更容易執行它的方法。 它包括用於所有主流核心本地檔案系統的單命令包裝器。
補丁在合併後將進行更多測試（包括 lockdep/kasan/preempt/etc. 變體），通常不需要提交者執行這些測試 - 但請仔細考慮您正在更改的內容以及哪些測試可能相關，例如，您是否正在處理棘手的記憶體佈局工作？kasan，您是否在進行鎖定工作？那麼 lockdep； ktest 包括您最可能需要的除錯構建型別的單命令變體。
此規則的例外是不完整的 WIP/RFC 補丁：如果您正在處理一些重要的事情，建議傳送 WIP 補丁，讓人們知道您正在做什麼，並確保您走在正確的軌道上。只需確保它包含一個簡短的說明，說明已完成的內容和未完成的內容，以避免混淆。
不需要嚴格遵守 checkpatch.pl（它的許多警告被認為是過時的），但儘量不要無故偏離太多。
專注於編寫易於閱讀且組織良好的程式碼；程式碼應該在美學上令人愉悅。
2.2. CI¶
與其在本地執行測試，不如在執行完整測試套件時，最好讓伺服器場並行執行，然後在漂亮的測試儀表板中獲得結果（可以告訴您哪些故障是新的，並以 git 日誌檢視顯示結果，從而避免了大多數二分查詢的需要）。
它存在 [2]，社群成員可以請求一個帳戶。 如果您在一家大型科技公司工作，您需要幫助支付伺服器成本才能獲得訪問許可權 - 但 CI 不僅限於執行 bcachefs 測試：它執行任何 ktest 測試（通常可以很容易地包裝可以在 qemu 中執行的其他測試）。
2.3. 其他需要考慮的事項¶
我們將如何除錯這段程式碼？ 是否有足夠的自省來診斷使用者機器上的某些東西何時開始變得不穩定？
我們不一定需要透過自省看到每個資料結構的每個欄位，但是將所有核心資料型別的重要欄位連線起來可以大大簡化除錯 - 一點深思熟慮的預見性大大減少了人們構建帶有除錯補丁的自定義核心的需要。
更廣泛地說，考慮可能需要的所有除錯工具。
它會使程式碼庫變得更混亂還是更少？ 我們也可以嘗試做一些組織工作嗎？
是否需要編寫新的測試？ 新的斷言？ 我們如何知道並驗證程式碼是否正確，如果出現問題會發生什麼？
我們還沒有自動化的程式碼覆蓋率分析或簡單的故障注入 - 但現在，假設我們有，並詢問它們可能會告訴我們什麼。
鑑於我們還沒有一種可以進行符合人體工程學的嵌入式正確性證明的系統語言，因此斷言非常重要。 在測試中遇到斷言比遊蕩到未定義的行為 la-la land 要好得多 - 使用它們。 明智地使用它們，而不是作為適當錯誤處理的替代品，但要使用它們。
是否需要進行效能測試？ 我們應該新增新的效能計數器嗎？
bcachefs 有一組持久的執行時計數器，可以使用“bcachefs fs top”命令檢視。 這應該讓使用者對他們的檔案系統當前正在做什麼有一個基本的瞭解。 如果您正在開發一項新功能或檢視舊程式碼，請考慮是否應該新增任何內容。
如果它是一項新的磁碟格式功能 - 是否已測試升級和降級？ （存在自動化測試，但由於磁碟映像管理的麻煩，它們不在 CI 中；協調以執行它們。）
2.4. 郵件列表，IRC¶
補丁應該傳送到列表 [3]，但許多討論和程式碼審查也發生在 IRC 上 [4]；許多人喜歡這種更具對話性的方法和更快的反饋。
此外，我們有一個活躍的使用者社群在做優秀的 QA 工作，主要存在於 IRC 上。 請利用該資源； 使用者反饋對於任何重要的功能都很重要，並在提交訊息中記錄它將是一個好主意。
參考資料