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 标签的开发者，请他们查看并提供他们的意见。