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