在 2004 年 Linux 内核峰会上，核心内核开发者宣布他们近期不会创建 2.7 开发内核。他们表示他们喜欢事情目前的进展方式，并且不想改变现状。这引起了很多困惑，因此本文旨在对此进行解释。

在 2.5 内核开发周期中，顶层维护者的流程发生了改变。在 Linus 开始使用 BitKeeper 版本控制系统之前，内核维护者会一次性向 Linus 发送 10-20 个补丁，然后等待他发布快照，以确定补丁是否已被采纳。如果没有，他们会再次尝试。这种方式在十多年里运行良好。

在 2.5 开发周期的早期，一场关于补丁丢失的激烈争论以 Linus 决定试用 BitKeeper 而告终。BitKeeper 开发者为清理内核开发者需要的一些功能进行了大量黑客式开发后，Linus 于 2002 年 2 月 2 日发布了 2.5.3 内核，并宣布他将使用 BitKeeper。这实际上并没有改变大多数内核开发者的工作方式。他们仍然将补丁发送给上层维护者并等待。但是对于决定使用 BitKeeper 的少数维护者来说，生活发生了很大变化。他们会创建一个 BitKeeper 树，用他们想要发送给 Linus 的更改填充它，然后将 Linus 指向它。他会将补丁吸收到他的树中，并合并与其他人的工作产生的任何小的冲突。

BitKeeper 带来了一些意想不到的后果。首先，每个人都可以在任何时候获得 Linus 树的最新视图。包括 Peter Anvin 和 Jeff Garzik 在内的几位开发者创建了使每日快照以补丁形式出现在 kernel.org 上的能力。在 BitKeeper 开发者的帮助下，他们还为这些版本控制系统的用户创建了 CVS 和 Subversion 仓库。

了解树的当前状态意味着维护者可以更快地向 Linus 发送补丁，并查看他何时接受了它们。他们可以立即提交更多更改，而不是等待两周才能获得新的快照。内核开发速度立即提高。

其次，每个被 Linus 树接受的补丁都开始发送到一个邮件列表，这使得每个人都可以看到更改。开发者可以观察内核所有部分正在发生的事情，查看变更日志条目中解释的原因，并指出问题。该列表增加了同行评审过程，使得新的错误能够更快地被注意到，同时开发区域仍然在开发者的脑海中记忆犹新。

2002 年 10 月 31 日，内核开发者宣布 2.6 功能冻结。2003 年 7 月 7 日，第一个 2.6.0-test1 内核发布，维护者流程再次发生变化。Andrew Morton 开始成为几乎所有补丁汇集到 Linus 的渠道。然而，使用 BitKeeper 的维护者仍然让他们的树被 Linus 直接拉取。最终，在 2003 年 12 月 17 日，2.6.0 内核发布，代表了 2.5 和 2.6 开发的 680 天里平均每小时 1.66 个更改。

接下来的五个 2.6.x 内核版本大约每月发布一次，每次发布包含 538-1,472 个更改。然后，随着 2.6.5 内核的发布，事情开始变得更快；2.6.6 发布了 1,757 个更改，而 2.6.7 则有 2,306 个更改。从 2.6.0 到 2.6.7，稳定内核以每小时 2.2 个补丁的速度变化，速度甚至高于“开发”内核。但是，2.6.7 内核是有史以来最稳定的 Linux 内核，通过了广泛的基准测试和回归测试。

核心内核开发者是否已经疯了，开始随意添加未经测试的代码？并没有。在 2.6 中，Andrew Morton 继续对所有提议的补丁进行暂存以进行测试，然后再发送给 Linus。使用 BitKeeper 的维护者会检查他们的补丁在 Andrew 树中的状态，如果没有发现问题，他们会要求 Linus 接受它们。

因此，现在所有的更改都正在 -mm 树中被用户测试。这与以前的做法不同。现在，补丁在被认为是可接受的之前，会在世界各地的用户那里进行测试、构建、使用和滥用。如果发现特定的补丁或一组补丁存在问题，Andrew 只需将它们从他的树中删除，并强制原始开发者修复这些问题。

由于更广泛的补丁测试能够进入树中，因此 2.6 的开发过程将包括以下步骤：1) Linus 发布 2.6 内核版本。2) 维护者用已经在 -mm 树中证明有效的补丁淹没 Linus。3) 几周后，Linus 发布 -rc 内核快照。4) 每个人从大量更改中恢复过来，并开始修复在 -rc 内核中发现的任何错误。5) 几周后，下一个 2.6 内核发布，循环重新开始。

但是，如果出现一组看起来非常庞大且具有侵入性的内核更改，则可能会分叉一个 2.7 内核来处理它。Linus 将会这样做，将新的实验性补丁放入该树中。然后，他将继续将所有正在进行的 2.6 更改拉入 2.7 内核，以使 2.7 内核稳定下来。如果事实证明 2.7 内核的方向不正确，则 2.7 内核将被删除，并且每个人都将继续使用 2.6 树。如果 2.7 树变得稳定，它要么被合并回 2.6 树，要么被声明为 2.8。

所有这一切都是因为内核开发者在当前情况下协同工作得非常好。像从 8k 到 4k 内核堆栈的更改这样可以说是相当具有侵入性的大型更改，正在被合并到“稳定”内核系列中。用户可以以大大缩短的延迟时间访问最新功能。发行版可以为其客户提供更稳定的内核，因为他们不必像 2.5 开发系列期间那样，将功能从“开发”内核反向移植到他们的“稳定”内核中。

更快的开发确保了内核内 API 将不断变化。Linux 一直如此，但现在更加明显。因此，任何未保存在主 kernel.org 树中的内核模块都将很快停止工作。至关重要的是，这些模块要添加到主内核树中。这样，任何 API 更改也会应用于受影响的模块，并且所有用户都将受益于这些模块提供的附加功能。

这个过程实际上并没有突然改变，它已经缓慢演变成一种运行良好的东西——实际上运行得非常好，以至于内核社区之外的任何人都没意识到它已经改变了，只知道他们正在使用有史以来最好的 Linux 内核。