Linux 内核连续性计划 (Jan 2026)：Linus 之后的变化

很多人把 Linux kernel 看作重力。它无处不在，维系着一切不至于分崩离析，而且没人愿意去想如果它出了故障会发生什么。

这份 Linux kernel continuity plan 是社区终于为这个去中心化项目中最中心化的部分写下的“万一”预案：即当负责合并代码的人无法履行职责时，由谁来将更改拉入 mainline。

在此之前，实际的答案是“社区总会解决的”，这通常也是事实。而 Linux kernel continuity plan 是当“通常”一词对于关键基础设施不再具有安慰力时，你所需要编写的预案。

Linux kernel continuity plan：对于基于 Linux 发布产品的团队的实际意义

如果你在 Linux 上构建产品，这与其说是关于个人，不如说是关于风险管理。这份 Linux kernel continuity plan 减少了关于最坏情况的不确定性，但它并不能神奇地消除你的运维责任。

该计划承认的技术现实是：内核开发分布在 100 多位拥有各自代码树的维护者手中，但最终合并到顶级仓库的设计本身就是一个瓶颈。这个瓶颈通常由 Linus Torvalds 处理。

那么，你应该做些什么改变呢？

将 Linux kernel continuity plan 视为加强你自身“变故后”应对能力的提醒：

• 如果你依赖特定的内核行为，请主动跟踪上游变更，而不仅仅是在 CI 挂掉的时候才去关注。

• 如果你进行大规模交付，请确保内部有内核问题升级路径（有人能进行 bisect、测试候选补丁，并能像成年人一样与上游沟通）。

• 如果你依赖 stable/LTS，请遵循 stable 邮件列表的工作流和回传（backport）预期，因为主线的连续性并不能取代下游维护的现实。（该计划关注的是主线的连续性，而不是你所用发行版的补丁堆栈。）

这些建议很乏味。乏味是好事。乏味正是你对操作系统的期望。

Linux kernel continuity plan：为什么“合并至主线”是需要预案的关键环节

该 Linux kernel continuity plan 侧重于流水线的最后一步：将更改拉入主线。这是位于大规模并行流程之上的中心化操作。

该文档甚至引用了一个真实的先例：在 2018 年 Linux 4.19 发布周期中，其他人在需要时承担了工作。该计划并非声称社区在失去某个人时就无能为力，而是表达“在风险如此之高的情况下，我们不应依赖即兴发挥”。

Linux kernel continuity plan：在此背景下“公交车指数”意味着什么

许多报道将其描述为“取代 Linus”的故事。更准确的表述应该是“提高公交车指数”。

该 Linux kernel continuity plan 明确是为顶级仓库的维护者不愿或无法履行职责（包括促进过渡）的情况而存在的。这就是公交车指数问题：在项目陷入困境之前，可以有多少人消失。

没错，Reddit 帖子里的网友开玩笑说这个流程听起来很复杂。这基本上是该评论区里唯一有用的“用户反馈”，而且这确实是一个现实问题：在真正需要它的那一天到来之前，正式治理总是看起来比非正式信任更奇怪。

Linux kernel 持续性计划：具体机制详解

关于 Linux kernel 持续性计划 最重要的一点是，它简短、具体且有明确的时间限制。它并不试图预先挑选继任者，而是定义了由谁召集决策以及决策流程必须启动的速度。

该计划还明确了 Linux Foundation 的职责：在技术咨询委员会 (TAB) 的指导下，Linux Foundation 负责支持并执行该计划。

Linux kernel 持续性计划：触发条件及其局限性原因

该 Linux kernel 持续性计划 适用于无法平稳交接的情况。它是针对“非正常过渡”场景的方案，而非常规的退休计划。

这一点至关重要，因为它避免了将治理变成一场持续的人气竞赛。除非有外部力量强制唤醒，否则该计划将一直处于休眠状态。

Linux kernel 连续性计划：组织者角色与 72 小时时钟

Linux kernel 连续性计划定义了一个 $ORGANIZER（组织者），通常由上一届 Maintainers Summit 的组织者担任，并由 TAB 主席作为备份。

一旦触发，组织者有 72 小时的时间与最近一届 Maintainers Summit 的受邀者开启讨论，并与这些受邀者及 TAB 安排一次会议（线上或线下），旨在最大限度地提高参与度。

在实践中，这就是“立即开始秘密会议”，只是少了些繁文缛节，多了更好的网络连接。

Linux kernel 连续性计划：谁来决定，以及决定什么

Linux kernel 连续性计划基于已被信任参与高语境对话的人群来选择决策小组：即 Maintainers Summit 的受邀者，外加 TAB。

如果过去 15 个月内未举行过 Maintainers Summit，则由 TAB 确定受邀者名单。该小组可根据需要引入其他维护者。

他们要决定什么？该计划非常谨慎：会议将审议顶级 kernel 仓库后续管理的各种方案，并预期所做出的选择能最大限度地保障项目和社区的长期健康。

这为多种结果留下了空间：

• 任命一位填补 Linus 目前角色的一级维护者，

• 将职责分散给多个人员，

• 或演变为更正式的委员会模式。

该计划并不强加特定的治理意识形态。它强加的是时间表。

Linux kernel 连续性计划：两周截止日期与公开沟通

Linux kernel 连续性计划要求在两周内，一名代表需通过 ksummit 邮件列表向更广泛的社区沟通后续步骤。

“两周”在这里起到了关键作用。它足够长，可以进行严肃的讨论；又足够短，可以避免陷入瘫痪，并确保下游生态系统不会陷入数月的疑虑中。

Linux kernel 连续性计划：为什么维护者峰会是选拔的核心

Linux kernel 连续性计划依赖于维护者峰会，因为这里已经是进行高信任、高上下文协作的场所。多份报告将该计划的出现与 2025 年维护者峰会的讨论联系在一起。

这是一种治理设计模式：当你可以将现有机构正式化时，不要发明新机构。

Linux kernel 延续性计划：它对当前的 Linux 治理意味着什么

Linux kernel 延续性计划是一份篇幅虽短但内涵丰富的文件：它标志着 Linux 治理正走向成熟，在纸面上演变为一种无需转变为公司组织架构图，就能在创始人离任后继续存续的模式。

Tom’s Hardware 坦率地阐述了部分动机：社区正在“老龄化”，随着关键人物年龄增长，依赖非正式的延续机制风险越来越大。

在 kernel.org 的文档中，其表述更为务实：项目是分布式的，但最终合并是中心化的，如果顶层维护者无法履行职责，必须“毫不延迟地”找到接替者。

Linux kernel 延续性计划：为什么正式化并不意味着社区之前存在缺陷

人们很容易将 Linux kernel continuity plan为“他们终于注意到了单点故障”。这并不完全公平。

Linux 以前也具备回退能力。文档明确提到，在需要时，其他人已经完成了合并工作。

改变的是记录升级路径的意愿。这是一种文化转变，而非技术修复。

Linux kernel 连续性计划：它不能解决什么（以及为什么这没关系）

该 Linux kernel 连续性计划 无法解决：

• 维护者倦怠、

• 审核带宽、

• 长期维护的经济效益，

• 有争议子系统的政治问题。

它也不保证每个人都会同意最终选择的结果。它保证的是，当大家在争论流程应该是怎样的时候，项目不会因此停滞。

这正是存续文档应有的适用范围。

Linux kernel 存续计划：人们真正搜索的常见问题

Linux kernel 存续计划常见问题：Linus Torvalds 要退休了吗？

存续计划本身并没有任何迹象表明他即将退休。相关报道明确指出，他目前尚未表达过停止领导 kernel 的意愿。

Linux kernel 存续计划常见问题：该计划记录在哪里？

该流程记录在 Linux kernel 文档中的“Linux kernel project continuity”部分（通常被称为“conclave”）。

Linux kernel 存续计划常见问题：谁来启动该流程？

该计划定义了一名召集人（Organizer），通常是上一届 Maintainers Summit 的组织者，并由 Linux Foundation TAB 主席担任备份。该召集人需在 72 小时内发起讨论。

Linux kernel 连续性计划常见问题解答：谁来决定后续步骤？

最近一次结束的 Maintainers Summit 受邀者与 TAB 共同组成核心决策小组。如果 15 个月内未举行峰会，则由 TAB 确定受邀者。

Linux kernel 连续性计划常见问题解答：社区必须多快做出决定？

该计划在 Organizer 外联后的 72 小时内启动。两周内，一名代表将在 ksummit 邮件列表中向更广泛的社区传达后续步骤。

Linux kernel 连续性计划常见问题解答：这会改变目前 Linux 补丁的合并方式吗？

日常工作流程保持不变：子系统维护者管理其代码树，更改向上流动，主线合并保持集中。该计划仅在顶层维护者无法履行职责或无法促进过渡时才会生效。

Linux kernel 连续性计划常见问题解答：为什么 Linux Foundation TAB 在这里很重要？

TAB 在流程中被指定为参与者，并且是在近期未举行峰会时可以确定受邀者的机构，而 Linux Foundation 则负责支持和实施该计划。