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 上。 请利用该资源； 用户反馈对于任何重要的功能都很重要，并在提交消息中记录它将是一个好主意。
参考资料