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