At the July 2004 kernel summit, it was decided that there was no need to fork a 2.7 kernel [forum] to introduce new functionality into the Linux kernel. Instead, the decision was made that it was possible for Andrew Morton [interview] and Linus Torvalds to continue working together to first merge things into Andrew's -mm tree, and then after testing the changes to merge them into Linus' mainline tree [story]. This of course led to discussion, with some confusion as to how the 2.6 kernel [forum] could be considered stable while new features were still being merged in [story]. During another short discussion nine months after this decision, Rik van Riel [interview] offered some insight into why the new development model works:
"Things get merged one change at a time, and stabilised one change at a time. This is a big change from the even/odd numbered kernel series, where sometimes a bug crops up without anybody knowing exactly what change introduced it. The current development model seems to go much smoother than anything I've seen before."
Linus Torvalds began working on an interim solution called "git" in the absence of BitKeeper [story]. A README included with the source describes it as, "a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently." The documentation goes on to describe two abstractions used by the tool, an "object database", and a "current directory cache". Objects in the object database are referred to by the SHA1 hash of their zlib compressed contents. The various supported object types include, "blobs" which are simply binary blobs of data with no added verification, "trees" which are lists of objects sorted by name, and "changesets" which provide a historical view of an object describing "how we got there, and why". The current directory cache is a binary file "which contains an efficient representation of a virtual directory content at some random time."
During the discussion regarding git and its rapid evolution, Linus explained, "in many ways you can just see git as a filesystem - it's content- addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a _filesystem_ person (hey, kernels is what I do), and I actually have absolutely _zero_ interest in creating a traditional SCM system." As for actual usage, Linus noted, "I think we can make the workflow look like bk, ie pretty much like "git pull" and "git push". And for well-behaved stuff (ie minimal changes to the same files on both sides) it will even be fast. I think." Read on for much of the resulting discussion which provides a fuller understanding of how the evolving tool will work.
Matt Dillon [interview] decided on an official version numbering scheme for DragonFlyBSD releases. First ruling out the usage of dates in each release, he settled on using odd numbers to denote a work in progress, and even numbers to denote releases. For example, 1.0, 1.2, 1.4, and so on would be considered releases, whereas 1.1, 1.3, 1.5, and so on would be considered works in progress.
Four tags will also be used, -CURRENT, -WORKING, -RELEASE and -STABLE. The -CURRENT tag indicates "a build based on the head of the CVS tree." The -WORKING tag indicates "a build based on our current stable tag". The -RELEASE tag indicates "a build based on a release branch." And the -STABLE tag indicates "a build based on a post-release branch." Matt adds, "you can probably see why I am also using odd/even numbering... so people can just glance at the number to get an idea of the relative time frame without necessarily understanding what all the keywords mean." Following this scheme, the next stable release will be DragonFly 1.2-RELEASE.
Greg KH and Chris Wright continue to finalize how the -stable Linux kernel tree will work in an email Greg described as, "everything you ever wanted to know about Linux 2.6 -stable releases." Provided as patches against the last official 2.6.x release, the -stable branch uses 2.6.x.y numbering. The list of requirements for includable patches [story] has been further refined, while a proceedure for submitting patches, specifics for a review cycle, and mention of a review committee were added. New patches will generally be in review for 48 hours before the patch is added to the -stable tree. If any single member of the review committee votes against the patch, it will be dropped from the queue and not included in a stable release. Greg explains that the review comittee is made up of "a number of kernel developers who have volunteered for this task, and a few that haven't." Security patches are accepted directly from the kernel security team [story], bypassing the normal review cycle.
This announcement was quickly followed by the release of 18.104.22.168. Greg explained, "it contains one patch, which is already in the -bk tree, and came from the security team (hence the lack of the longer review cycle)." The changlog describes the event poll fix as, "return proper error on overflow condition".
Greg KH announced the first maintenance release of the 2.6.11 kernel [story], 22.214.171.124. Quickly acting on the recent lengthy discussion regarding kernel release numbering [story] [story], Greg and Chris Wright have begun to maintain this branch. With each 2.6.x release, they will maintain 2.6.x.y releases available from your nearest kernel.org mirror. This first maintenance release includes three simple patches, not including the makefile change, addressing a problem with keyboards on Dell machines, and raid6 compilation on the ppc architecture. Andrew Morton [interview] noted that he has additional fixes appropriate for this tree that will likely lead to a 126.96.36.199 release in the relatively near future.
Greg went on to highlight the requirements for patches to be able to be merged into this new tree: they must be no bigger than 100 lines, they must fix only one thing, they must fix real bugs that are confirmed to be affecting people, and they must fix a build error, an oops, a hang, or a real security issue. Patches explicitly not allowed include things to fix "theoretical race conditions" without an exploit, or "trivial" fixes like spelling changes or whitespace cleanups. Greg described the effort's mantra as "release early and often".
Linux creator Linus Torvalds started a lengthy discussion on the lkml regarding release numbering for the Linux kernel. Some have complained about kernel stability with the new development model discussed back in mid-2004 [story] in which active development occurs in the "stable" 2.6 kernel. In his recent email, Linus explained, "the problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting. That said, it did serve a purpose - people kind of knew where they stood, even though we always ended up having to have big changes in the stable tree too, just to keep up with a changing landscape." His new proposal involves still using an even and odd numbering scheme, but on a smaller level. Thus, the upcoming 2.6.12 would be "stable" in that it should only contain bugfixes over 2.6.11. Then 2.6.13 would be more development oriented, including some larger changes. These larger changes would again stabalize in 2.6.14, and so on. He adds, "we'd still do the -rcX candidates as we go along in either case, so as a user you wouldn't even _need_ to know, but the numbering would be a rough guide to intentions. Ie I'd expect that distributions would always try to base their stuff off a 2.6.<even> release."
The lengthy discussion that followed was a collection of mixed reactions. Some liked the proposal, but others were confused as to what it was supposed to solve. Essentially the idea seems to be to get more people to test the kernel, as only with more testers can bugs be found. The current strategy of using a series of "-rc" kernels [story] is confusing to many as in most projects this indicates a "release candidate", or something thought to be stable, whereas with the Linux kernel an -rc release is frequently where the active development takes place. As the common user has come to realize this, the -rc kernels have gotten less testing. Linus says, "that's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a 'real release'." Andrew Morton [story]'s -mm tree is intended to weed out obvious errors with big changes before merging patches upstream in the mainline kernel, but again as it frequently proves less stable it tends to get less testing.
At the July 2004 kernel summit, it was decided that the current 2.6 development process with teamwork between Andrew Morton [interview] and Linux creator Linus Torvalds was proving quite effective. The process involves using Andrew's test -mm tree [forum] as a staging area for patches prior to going into Linus' mainline tree [forum]. The system has allowed for continued evolution and new features in the 2.6 stable kernel, however it has also lead to a fair amount of discussion and debate [story]. Much of the concern is that with new features constantly being introduced, true stabilization may not be possible.
One theory presented on the lkml was that the process has changed because, "these days nobody wants to be a stable-release maintainer anymore. It's boring." 2.2 maintainer Alan Cox [story] disagreed, "that depends what kind of an engineer you are. Just as there are people who love standards body work and compliance testing/debugging there are people who care about stable trees." When asked if he was willing to maintain a stable 2.6.x kernel, Alan replied, "I'll do it if Linus wants". That is, while 2.6.10 is being developed, the suggestion is to continue to stabalize 2.6.9, releasing 188.8.131.52, 184.108.40.206, etc. And when 2.6.10 is released, to then focus on stabalizing it. Alan already maintains a 2.6-ac patchset [forum] which includes a growing number of bugfixes. However he notes that it is not intended to be all-inclusive, "the goal of -ac is to contain the stuff I personally consider important. A lot of the smaller bugfixes individually are fine but a 'complete set of bugfixes' turns into a large change set and then needs an entire validation and release cycle of its own."
With the release of Linux kernel 2.6.9-rc1, Linus Torvalds further refined the new kernel development model [story] first proposed at the 2004 kernel summit [story]. The earlier 2.6.8 kernel was quickly followed by 220.127.116.11 [story] to address an oops in NFS. With today's 2.6.9-rc1 Linus explained, "administrative trivia, and one thing I agonized over: should I make the patches relative to 2.6.8 or 18.104.22.168? I decided that since there is nothing that says that 'basic bug-fix' releases for a previous release might not happen _after_ we've done a -rc release for the next version, I can't sanely do patches against a bugfix release."
With Linus having returned from a week-long vacation, he noted that there were "tons of patches merged", specially thanking Andrew Morton [interview] "who synced up 200+ patches". Regarding the specific changes in this release candidate, Linus said they are "all over: arm, ppc, sparc, acpi, i2c, usb, fbcon, ntfs, xfs, nfs, cpufreq, agp, sata, network drivers - you name it. Most of the changes are fairly small, but there's a lot of them."
Linus Torvalds released the official 2.6.8 kernel noting, "the major patches since -rc4 [story] were some sparc64 and parsic updates, but there's some network driver and SATA updates and a few ARM patches too. And a use-after-free fix in MTD." The latest Linux kernel can always be obtained from a kernel.org mirror.
Shortly after the release, an easily reproducible Oops was reported from accessing a mounted NFS filesystem. Linus acknowledged the bug, and decided to release a quick 22.214.171.124, "to make it usable for people with NFS." When asked why it was named this instead of 2.6.9 using the long-standing three-digit kernel versioning, Linus explained:
"Well, we've been discussing the 2.6.x.y format for a while [story], so I see this as an opportunity to actually do it... Will it break automated scripts? Maybe. But on the other hand, we'll never even find out unless we try it some time."
An interesting thread on the lkml began when Greg KH submitted a patch for the 2.6 kernel saying, "Ok, to test out the new development model, here's a nice patch that simply removes the devfs code." This was quickly followed with a comment by Oliver Neukum who said, "may I point out that 2.6 is supposed to be a _stable_ series?" In one branch of the thread, the usefulness of devfs was examined.
In another thread, discussion was focused on this "new development model". Jonathan Corbet explained that Linus Torvalds and Andrew Morton [interview] were very happy with the results of their recent teamwork, and saw no immediate pressure to fork a 2.7 development branch. On the contrary, they intend to keep at it as they've been, with things first going into Andrew's -mm patchset [story] for testing, then eventually being merged into the mainline 2.6 kernel. Jonathan went on to explain, "Andrew stated his willingness to consider, for example, four-level page tables, MODULE_PARM removal, API changes, and more. 2.7 will only be created when it becomes clear that there are sufficient patches which are truly disruptive enough to require it. When 2.7 *is* created, it could be highly experimental, and may turn out to be a throwaway tree." And he summarized:
"Andrew's vision, as expressed at the summit, is that the mainline kernel will be the fastest and most feature-rich kernel around, but not, necessarily, the most stable. Final stabilization is to be done by distributors (as happens now, really), but the distributors are expected to merge their patches quickly."
Linux creator Linus Torvalds began a recent email, "this is a request for discussion.." describing a method of tracking how patches find their way into the Linux kernel. The incentive for this change in process was made clear:
"Some of you may have heard of this crazy company called SCO (aka "Smoking Crack Organization") who seem to have a hard time believing that open source works better than their five engineers do. They've apparently made a couple of outlandish claims about where our source code comes from, including claiming to own code that was clearly written by me over a decade ago."
He notes that though people have proven to be quite good at debunking these claims, the effort has been tedious. "So, to avoid these kinds of issues ten years from now, I'm suggesting that we put in more of a process to explicitly document not only where a patch comes from (which we do actually already document pretty well in the changelogs), but the path it came through." Read on for Linus' complete description of how this process would work.