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:条目标识自己。错误分类员：仔细检查传入的错误报告，以确定应将报告转发给谁的人员。
错误分类员应该在内核 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. 审查节奏¶
通常，请至少等待一周后再请求反馈。要查找审查者，请查阅 MAINTAINERS 文件，或要求已对 XFS 更改添加了 Reviewed-by 标记的开发者查看并提供他们的意见。