特性和驱动维护者¶
术语“维护者”涵盖了非常广泛的参与程度，从几乎全职处理补丁和拉取请求的人员到负责小型特性或驱动的人员。
与本章的大部分内容不同，本节是为后者（人数较多的群体）准备的。它提供了关于小型代码段维护者的期望和责任的提示和描述。
驱动程序和类似的代码通常没有自己的邮件列表和 git 树，而是在更大的子系统的列表中发送和审查补丁。
职责¶
维护工作量通常与代码库的大小和受欢迎程度成正比。小型特性和驱动程序应该只需要相对较少的维护。然而，当工作确实到来时（以需要审查的补丁、用户错误报告等形式），必须及时采取行动。即使某个特定的驱动程序每月或每季度只看到一个补丁，一个子系统也可能有一百个这样的驱动程序。子系统维护者不能承受等待很长时间才收到审查者的反馈。
对响应时间的具体期望将因子系统而异。子系统为其自身设置的补丁审查 SLA 有时可以在子系统文档中找到。如果找不到，根据经验，审查者应该尝试比子系统维护者的通常补丁审查延迟更快地做出响应。由此产生的期望可能从快速发展的子系统（例如网络）的两个工作日到内核中移动较慢的部分的几周不等。
邮件列表参与¶
Linux 内核使用邮件列表作为主要的沟通形式。维护者必须订阅并关注适当的子系统范围的邮件列表。可以通过订阅整个列表或使用更现代的选择性设置，例如 lei。
维护者必须知道如何在列表上进行沟通（纯文本，没有侵入性的法律页脚，没有顶部帖子等）
审查¶
维护者必须审查所有仅触及其驱动程序的补丁，无论多么微不足道。如果补丁是树范围的更改并修改了多个驱动程序，是否提供审查由维护者决定。
当一段代码有多个维护者时，来自单个维护者的 Acked-by 或 Reviewed-by 标签（或审查评论）足以满足此要求。
如果特定更改的审查过程或验证将花费比子系统的预期审查时间更长的时间，维护者应回复提交，表明正在进行工作，以及何时可以预期完整结果。
重构和核心更改¶
有时需要更改核心代码以提高内核的整体可维护性。维护者需要参与并帮助指导和测试对其代码的更改，以适应新的基础设施。
错误报告¶
维护者必须确保及时解决报告给他们的代码中的严重问题：回归、内核崩溃、内核警告、编译错误、死锁、数据丢失以及其他类似范围的错误。
此外，如果报告质量合理或表明可能存在严重问题（尤其是在 MAINTAINERS 文件中具有代码库的Supported状态的情况下），维护者也应响应有关其他类型错误的报告。
开放式开发¶
关于用户报告问题的讨论以及新代码的开发应以适用于较大子系统的方式进行。单个公司内部的开发通常是在封闭的环境中进行的。但是，社区成员发起的开发和讨论不得从公开论坛重定向到封闭论坛或私人电子邮件对话。对此指导的合理例外情况包括关于安全相关问题的讨论。
选择维护者¶
上一节描述了维护者的期望，本节提供了有关选择维护者的指导并描述了常见的误解。
多个维护者¶
现代最佳实践表明，任何代码都应至少有两个维护者，无论多么微不足道。它可以分散负担，帮助人们休假，防止倦怠，培训社区新成员等等。即使有一个明显的完美候选人，也应该找到另一个维护者。
维护者必须是人，因此，将邮件列表或群组电子邮件添加为维护者是不可接受的。信任和理解是内核维护的基础，而你无法通过邮件列表建立信任。除了人类之外，拥有邮件列表是完全可以的。
公司结构¶
对于外行来说，Linux 内核可能类似于一个以 Linus 为 CEO 的等级组织。虽然代码以分层方式流动，但公司模板不适用于此。Linux 是一种无政府状态，由（很少表达的）相互尊重、信任和便利性维系在一起。
所有这一切都说明，经理几乎永远不会成为好的维护者。维护者职位更类似于随叫随到的轮换，而不是权力的职位。
以下被选为维护者的人的特征是明显的危险信号
社区不熟悉，以前从未向列表发送过电子邮件
没有编写任何代码
（当开发是承包的）为支付开发的公司的雇员，而不是完成工作的公司的雇员
不合规¶
子系统维护者可以从 MAINTAINERS 文件中删除不活跃的维护者。如果维护者是重要的作者或在代码开发中发挥了重要作用，则应将其移动到 CREDITS 文件中。
删除不活跃的维护者不应被视为惩罚性行为。拥有不活跃的维护者会产生实际成本，因为所有开发人员都必须记住在讨论中包括维护者，并且子系统维护者会花费脑力来弄清楚如何征求反馈。
子系统维护者可以删除因缺乏维护的代码。
子系统维护者可以拒绝接受来自反复忽视其维护职责的公司的代码。