功能和驱动维护者¶
“维护者”一词涵盖了非常广泛的参与程度,从几乎全职处理补丁和拉取请求的人员,到负责小型功能或驱动程序的人员,均属此范畴。
与本章的大部分内容不同,本节面向的是后一类(人数更多)群体。它提供了关于一小部分代码的维护者的提示,并描述了他们的期望和职责。
驱动程序及类似代码通常没有自己的邮件列表和 Git 树,而是通过较大的子系统的列表来发送和审查补丁。
职责¶
维护工作的数量通常与代码库的大小和受欢迎程度成正比。小型功能和驱动程序所需的维护量相对较少。尽管如此,当工作(以需要审查的补丁、用户错误报告等形式)到来时,必须迅速采取行动。即使某个特定驱动程序每月或每季度只收到一个补丁,一个子系统也可能有一百个这样的驱动程序。子系统维护者不能长时间等待审查者的回复。
对响应时间的具体期望因子系统而异。子系统为自身设定的补丁审查 SLA(服务水平协议)有时可以在子系统文档中找到。如果找不到,作为经验法则,审查者应尝试比子系统维护者的常规补丁审查延迟更快地响应。由此产生的期望可能从快速子系统(例如网络)的两天工作日到内核中较慢部分的几周不等。
邮件列表参与¶
Linux 内核使用邮件列表作为主要的沟通形式。维护者必须订阅并关注相应的子系统邮件列表。可以通过订阅整个列表,也可以使用更现代、更具选择性的设置,例如 lei。
维护者必须知道如何在邮件列表中进行沟通(纯文本、无侵入性法律页脚、不置顶回复等)。
审查¶
维护者必须审查所有专门涉及其驱动程序的补丁,无论其多么微不足道。如果补丁是涉及整个代码树的更改并修改了多个驱动程序,则是否提供审查由维护者决定。
当一段代码有多个维护者时,来自单个维护者的 Acked-by
或 Reviewed-by
标签(或审查意见)足以满足此要求。
如果对特定更改的审查过程或验证将耗时超过子系统预期的审查时间线,维护者应回复提交,表明工作正在进行中,并告知何时可以期待完整结果。
重构和核心更改¶
偶尔,核心代码需要更改以提高整个内核的可维护性。维护者应参与其中,协助指导和测试其代码的更改,使其适应新的基础设施。
错误报告¶
维护者必须确保及时解决向他们报告的代码中的严重问题:包括回归、内核崩溃、内核警告、编译错误、死锁、数据丢失以及其他类似范围的错误。
此外,如果报告质量合理或表明可能存在严重问题,维护者还应回应其他类型的错误报告——特别是当他们在 MAINTAINERS 文件中拥有代码库的受支持状态时。
开放开发¶
关于用户报告的问题以及新代码的开发应以大型子系统惯用的方式进行。在单一公司内部进行的开发通常是在幕后进行的。然而,社区成员发起的开发和讨论不得从公开论坛重定向到封闭论坛或私人电子邮件对话。此指导的合理例外情况包括关于安全相关问题的讨论。
选择维护者¶
上一节描述了对维护者的期望,本节提供了选择维护者的指导并描述了常见的误解。
多位维护者¶
现代最佳实践要求任何一段代码都应该至少有两名维护者,无论其多么微不足道。这可以分担负担,帮助人们休假,防止倦怠,培养社区新成员等等。即使有一个明显的完美人选,也应该找到另一位维护者。
维护者必须是人类,因此,将邮件列表或群组电子邮件添加为维护者是不可接受的。信任和理解是内核维护的基础,而无法与邮件列表建立信任。在人类维护者之外拥有一个邮件列表是完全可以的。
公司结构¶
对一个局外人来说,Linux 内核可能看起来像一个以 Linus 为首席执行官的层级组织。尽管代码以层级方式流动,但公司的模板不适用于此。Linux 是一个由(鲜有表达的)相互尊重、信任和便利所维系的无政府状态。
总而言之,管理者几乎从不成为优秀的维护者。维护者职位更像是轮值的随叫随到,而非权力职位。
被选为维护者的人员若具有以下特征,则明确亮起红灯:
社区不认识,之前从未向邮件列表发送过电子邮件
不是任何代码的作者
(当开发是承包的)为支付开发费用的公司工作,而不是实际完成开发的公司
不合规¶
子系统维护者可以从 MAINTAINERS 文件中移除不活跃的维护者。如果该维护者是重要的作者或在代码开发中发挥了重要作用,他们应该被移到 CREDITS 文件中。
移除不活跃的维护者不应被视为一种惩罚性行为。拥有不活跃的维护者会带来实际成本,因为所有开发人员都必须记住在讨论中包含维护者,并且子系统维护者需要花费精力来思考如何征求反馈。
子系统维护者可能会因缺乏维护而移除代码。
子系统维护者可能会拒绝接受那些屡次忽视其维护职责的公司的代码。