维护者入口配置文件
维护者入口配置文件是对顶层流程文档（提交补丁、提交驱动程序等）的补充，其中包括子系统/设备驱动程序本地习俗以及有关补丁提交生命周期的详细信息。贡献者使用此文档来调整他们的期望并避免常见错误；维护者可以使用这些配置文件来查看各个子系统，以便在常规实践上达成一致。
概述
介绍子系统的运作方式。虽然 MAINTAINERS 告诉贡献者在哪里发送哪些文件的补丁，但它并未传达其他子系统本地基础设施和开发机制。
考虑的示例问题：
- 当补丁被应用到本地树或合并到上游时是否有通知？
- 子系统是否有 patchwork 实例？状态变化是否会通知？
- 是否有机器人或 CI 基础设施监视列表，或者子系统使用自动化测试反馈来控制接受？
- 被拉入 -next 的 Git 分支？
- 贡献者应该提交到哪个分支？
- 有关其他维护者入口配置文件的链接？例如，设备驱动程序可能指向其父子系统的入口。这使贡献者了解维护者在提交链中可能具有的义务。
提交检查清单附录
列出超出常规“提交检查清单”之外的强制和建议标准，以便补丁被认为足够健康，值得维护者关注。例如：“通过 checkpatch.pl，无错误或警告。通过 $URI 中详细的单元测试”。
提交检查清单附录还可以包括有关相关硬件规格状态的详细信息。例如，子系统是否要求在特定修订版本上发布规格，才能考虑接受补丁。
关键周期日期
提交者常见的一个误解是，在合并窗口关闭之前可以随时发送补丁，并且仍然可以考虑用于下一个 -rc1。实际情况是，大多数补丁需要在合并窗口打开之前在 linux-next 中进行充分测试。为提交者澄清关键日期（以 -rc 发布周为单位），以便补丁可能被考虑合并，以及何时需要等待下一个 -rc。至少包括：
-
用于新功能提交的最后一个 -rc：针对下一个合并窗口的新功能提交应在此时考虑首次发布以供审查。在此点之后提交的补丁应明确表示它们针对下一个+1合并窗口，或者应提供充分理由说明为何它们应该按加快的时间表考虑。一个一般的指导原则是告知贡献者，新功能提交应在 -rc5 之前出现。
-
合并功能的最后一个 -rc：合并决策的截止日期。向贡献者指出尚未应用的补丁集需要等待下一个+1合并窗口的时间点。当然，并没有义务接受任何给定的补丁集，但如果审查在此时尚未结束，预期是贡献者应该等待并重新提交到下一个合并窗口。
可选：
- 第一个 -rc，在该基线分支（在概述部分列出）应被视为准备接受新提交的时间点。
审查节奏
贡献者最大的焦虑之一是在发布补丁集后多久才应该催促反馈。除了指定重新提交前等待多长时间外，此部分还可以指示首选的更新方式，例如重新发送完整系列，或者私下发送提醒邮件。此部分还可以列出此代码区域的审查工作方式以及获取反馈的方法，这些方法不一定直接来自维护者。
现有配置文件
目前，现有的维护者配置文件列在此处；我们可能会在不久的将来做一些不同的事情。
- 文档子系统维护者入口配置文件
- LIBNVDIMM 维护者入口配置文件
- 面向开发者的 RISC-V 架构维护指南
- 媒体子系统配置文件
- 针对 vfio-pci 设备特定驱动程序变体的接受标准
- Linux NVMe 功能和特性策略
- XFS 维护者入口配置文件