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."

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."

A brief thread on the lkml discussed whether or not Reiser4 would soon be stable enough to be merged into the 2.6 kernel as an 'experimental filesystem'. When it was suggested that this might be overly optimistic, that the filesystem may best go into the 2.7 development kernel [forum] first, Hans Reiser disagreed, "I don't think it is vastly optimistic, I hope we can send something in next month". He went on to explain, "we will have something we think is appropriate for inclusion as an experimental feature very soon now. Because our test scripts have become much more sophisticated, it means more when we say we cannot crash it, and it will go from experimental to stable faster than V3 did. I won't predict how fast."

Jens Axboe, maintainer of the block layer and several CD-ROM drivers, suggested that it would be unwise to merge the code so quickly, instead preferring a much lengthier period of user testing. He explains, "I don't doubt you have great testing scripts, but nothing beats real life testing." During a discussion in late August [story], 2.6 kernel maintainer Andrew Morton [interview] indicated that he would be willing to merge Reiser4 into his -mm patchset [howto].