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.

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 2.6.9.1, 2.6.9.2, 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."

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.