LWN: linux-next 的最佳实践

By *Jonathan Corbet*, December 12, 2025 Gemini translationhttps://lwn.net/Articles/1050027/

维护者峰会 (Maintainers Summit)

内核开发流程中的关键组件之一是 linux-next 仓库 (repository)。每天，大量的分支 (branches) 会被合并进 linux-next 并进行集成，每个分支都包含打算用于下一个内核开发周期的提交 (commits)。如果分支之间存在冲突，linux-next 流程就会将其暴露出来。理论上，许多其他类型的问题也可以被发现。然而，一些开发人员认为 linux-next 的工作效果并没有达到预期。在 2025 年维护者峰会上，协助维持 linux-next 运行的 Mark Brown 主持了一场关于如何使其更有效地工作的会议。 

他说，这次会议的想法始于他听到有关某些类型的“奇怪修复”在进入主线 (mainline) 之前没有出现在 linux-next 中的投诉。维护者可能管理着许多分支，而其中一些分支并没有被拉入 linux-next。当维护者在将提交发送到主线之前对其进行拣选 (cherry-pick) 时，也会产生额外的问题，这使得追踪这些提交在 linux-next 中出现时的状态变得更加困难。此外，他还提到有一位维护者拒绝将修复程序放入 linux-next，因为他不希望这些修复程序与面向特性的更改一起进行测试。 

他询问与会人员是否应该向维护者施加更多压力，要求他们将自己的仓库放入 linux-next。似乎没有人反对这个想法。 

Linus Torvalds 有不同的抱怨：有些修复确实进入了 linux-next，但随后并没有转发给他以便合并到主线。在某些情况下，内核存在已知错误，修复程序已经准备就绪，但他却没有收到。 

Torvalds 面临的另一个问题是带病补丁破坏了所有人的 linux-next，干扰了它的主要用途。他一再要求从 linux-next 中直接移除有问题的仓库，并在发生这种情况时通知他。 

Steve Rostedt 表示，他偶尔会对自己出现在 linux-next 中的仓库进行变基 (rebasing)，主要是为了给提交添加标签。这可能会产生与拣选类似的效果，即提交的 ID 会发生变化。Torvalds 说，这种习惯也会在 linux-next 中引起麻烦，但 Mark Brown 认为，只有在其他人在已变基的仓库基础上进行构建时，变基才会真正成为问题。他说，在拣选方面最容易出问题的树是 DRM（图形）子系统，该子系统对补丁进行了大量的拣选。DRM 维护者 Dave Airlie 回应称，该子系统的规模决定了必须进行拣选。他说，所有其他子系统都有同样的问题，只是它们还没有大到让这一点变得显而易见。他表示愿意让在场的维护者为 DRM 开发一套更好的流程，但他不相信他们能做到。 

Torvalds 重复道，他希望看到当带病提交破坏 linux-next 时能产生后果，即违规仓库需要被剔除——至少是暂时剔除。一旦相关维护者确认并修复了问题，该仓库将被允许重新进入。如果问题没有得到修复，那么该仓库就应该被排除在外，并且在下一个合并窗口 (merge window) 期间不予提取。 

Ted Ts'o 表示，文件系统开发人员在测试 linux-next 时经常遇到问题，这些问题是由其他子系统引入的错误引起的。作为回应，linux-next 维护者 Stephen Rothwell 建立了一个流程，即首先拉入文件系统树，并在该过程完成后设置 fs-next 标签，然后再拉入其他仓库。这创建了一种有限的 linux-next，仅包含文件系统树和文件系统子系统所依赖的其他少数树，而不包含内核社区正在进行的其余大部分工作。Ts'o 说，linux-next 作为一个整体太不稳定了，但 fs-next 对测试很有用。 

Arnd Bergmann 说，并不是所有的子系统都是平等的，优先处理文件系统仓库是有道理的。该领域出错的代价尤其高昂。Miguel Ojeda 建议对其他更高级别的子系统采用类似的流程，先将它们合并到一个侧分支，然后再将结果合并到 linux-next 中。这将创建一种两级流程，在将所有内容放在一起之前，先集成内核的广泛区域。 

Airlie 说，在 rc1 版本发布前后破坏 linux-next（以及主线）是可以预料的，但每天都破坏它的代价太高了。他说，这会导致错误的人发现问题。Torvalds 表示，真正的开发团队应该在自己的分支上运行持续集成 (CI, continuous-integration) 测试，并且只偶尔测试 linux-next。他说，要求开发人员调试由其他子系统引入的问题是不合理的。他补充说，真正的问题在于，一些仓库显然根本没有经过任何测试。他说，这种情况经常发生在较小的子系统中，而 linux-next 在这种情况下并没有真正的帮助。 

Mark Brown 同意维护者应该最关心自己的仓库，但也表示关注 linux-next 的整体情况仍然是值得的；这增加了问题背后的元凶在带病提交进入主线之前将其修复的机会。Ojeda 说，他每天都必须测试 linux-next，以发现影响 Rust 构建的问题。 

Mark Brown 询问 linux-next 本身可以运行哪些测试来帮助解决 Rust 问题，并得到了一些建议，但他想知道应该测试哪些特定的配置。Torvalds 担心，如果测试了某些特定配置，其他人将只使用这些配置进行测试，而他仍然会遇到在其他配置中出现的“奇怪错误”。Ojeda 说，他不希望人们使用固定的配置进行测试；相反，他们应该使用自己的配置，并看看具体会出现哪些问题。 

Airlie 说，部分问题在于很多测试是在持续集成系统中完成的，但实际上没有人用他们的新代码启动笔记本电脑。因此，系统中真正显示屏幕文本的部分没有得到检查，并且不可避免地会崩溃。 

Jiri Kosina 询问，既然这些仓库应该已经被拉入 linux-next 并在那里进行了构建测试，那么 Torvalds 在提取仓库时遇到的构建问题是如何发生的。Torvalds 回答说，顺序问题是问题的根源之一；一个仓库会隐式地依赖于另一个仓库中的提交，而 linux-next 提取仓库的顺序隐藏了这个问题。然而，更常见的是，Torvalds 发现基本配置根本没有经过测试。他补充说，allmodconfig 构建（将整个内核构建为可加载模块）会导致某些代码被禁用，从而可能隐藏问题。结果是，有些问题只有在他使用自己的个人配置构建内核时才会遇到。 

Ts'o 担心从 linux-next 中删除仓库会导致测试覆盖率下降；他说，有必要以公开的方式采取这一行动。Torvalds 表示，他希望在合并窗口即将开启前收到一封自动邮件，告诉他哪些仓库已被禁用。 

Torvalds 说，在合并窗口期间，他通常每天进行大约 30 次合并。在此期间，构建失败相对较少；在整个合并窗口期间可能会发生两到三次，但它们仍然令人恼火且没有必要。 

Jakub Kicinski 表示，他经常比 linux-next 更早发现合并冲突，并想知道他是否应该发送解决方案。Torvalds 说，他不看维护者完成的冲突解决方案，至少在他自己完成解决之前不看。但在事后对照检查他的工作时，拥有解决方案可能会有所帮助。对于 Rust 代码中的冲突，他确实依赖他人的解决方案，因为他对自己的能力不太自信。 

会议结束时，Rostedt 询问维护者在将错误修复程序发送给 Torvalds 之前应该在 linux-next 中保留多久。答案是，如果这是一个影响他人的错误，修复程序应该在下一个 rc 版本发布之前发送——至少对于明显的修复是这样。但是，如果修复不明显，则应花费更多时间以确保修复是正确的。 

LWN 评论概述

评论区对 Linus Torvalds 提出的“对破坏构建的维护者实施惩罚”表示强烈支持。多位开发者指出，目前一些子系统维护者对 linux-next 的稳定性缺乏责任感，甚至在明知代码有问题时仍推迟修复，导致整个社区开发受阻。针对 Rust 引起的频繁构建中断，讨论中出现了分歧：有人认为 Rust 团队应在更多非主流架构上进行预测试，而不是让其他开发者承担调试成本。此外，有评论者强调硬件厂商应更积极地参与 linux-next 测试，因为这是在代码进入主线前拦截兼容性问题的最后机会。共识倾向于：如果补丁不能在当天修复，维护者应立即撤回（back out）相关更改，以维护开发树的整体可用性。