"To quote you a number of years ago: 'Linux is evolution, not intelligent design'," noted Greg KH, quoting Linux creator Linus Torvalds. Linus expanded on the statement, "evolution often does odd (and 'suboptimal') things exactly because it does incremental changes that DO NOT BREAK at any point." He continued, "in other words, exactly *because* evolution requires 'bisectability' (any non-viable point in between is a dead end by definition) and does things incrementally, it doesn't do big flips." When alternative examples in evolution were pointed out, Linus suggested that the kernel was much simpler than a mammal and more similar to bacteria:

"In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). In other words, all of these choices are a matter of 'balance'. In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, 'just because' (or rather, because the cost of carrying it around is so small that nobody cares)."

"Andrew [Morton] was looking for someone to run a linux-next tree that just contained the subsystem git and quilt trees for 2.6.x+1 and I (in a moment of madness) volunteered. So, this is to announce the creating of such a tree," began Stephen Rothwell, resulting in a lengthy thread discussing the current Linux kernel development process. In a follow up email announcing the first linux-next release, Stephen went on to explain, "it has two branches - master and stable. Stable is currently just Linus' tree and will never rebase. Master will rebase on an almost daily basis (maybe slower at the start)." He then detailed the master branch:

"The tree consists of subsystem git and quilt trees. Currently, the quilt trees are integrated by importing them into appropriately based git branches and then merging those branches. This has the advantage that any conflict resolution will onlt have to happen once at the merge point rather than, possibly, several times during the series. However, I am considering just applying the quilt trees on top of the current tree to get a result more like Linus' tree - we will see. The git trees are obviously just merged."

One of the goals of the new tree is to get subsystem maintainers more involved in managing merge conflicts by quickly notifying all involved when things break, and automatically dropping the offenders until build problems are fixed. Andrew plans to base his -mm kernel on the new linux-next tree, providing a stabler test branch for code before it's merged into Linus' mainline kernel tree.

"I re-ran some statistics the other day on our kernel development rate, and changed my formula after Andrew accused me of severely undercounting the rate of change," noted Greg KH during a discussion about the stability of the Linux kernel while undergoing significant changes. He continued, "turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did: lines added per day, 4945; lines removed per day, 2006; lines modified per day, 1702". Greg added:

"And note, that is real stuff, not renames or file moves at all, git handles not reporting that. That's for the 99 days that it took to do 2.6.24-rc8 (I need to re-run the scripts now that 2.6.24 is out.) It's fricken scarily amazing that things are still working at all... Just something to make you all sleep well at night :)"

"This is the listing of the open bugs that are relatively new, around 2.6.22 and up. They are vaguely classified by specific area," Natalie Protasevich said, posting a current list of bugs each linking to an appropriate bugzilla.kernel.org entry. Andrew Morton reviewed the list, noting "no response from developers" in response to many of the bugs. David Miller pointed out that in some cases this wasn't true, referring to 46 bug fixes queued in his networking tree and another 10 already pushed upstream, "when someone like me is bug fixing full time, I take massive offense to the impression you're trying to give especially when it's directed at the networking. So turn it down a notch Andrew." Andrew wasn't convinced, "first we need to work out whether we have a problem. If we do this, then we can then have a think about what to do about it. I tried to convince the 2006 KS attendees that we have a problem and I resoundingly failed. People seemed to think that we're doing OK." He continued:

"This is not a minor matter. If the kernel _is_ slowly deteriorating then this won't become readily apparent until it has been happening for a number of years. By that stage there will be so much work to do to get us back to an acceptable level that it will take a huge effort. And it will take a long time after that for the kerel to get its reputation back. So it is important that we catch deterioration *early* if it is happening."

"Quite frankly, at least for me personally, what I would rather have [...] is a less rigid maintainership structure," Linus Torvalds proposed. He went on to explain, "let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem." He noted that git is an excellent tool for spreading out maintenance, then added, "but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries." Linus continued:

"I've personally always been against _strict_ maintainer lines, so I've always taken stuff 'past' the maintainer anyway (and sometimes maintainers have complained, because they feel like they 'own' their subsystem, and I either tell them to stuff it, or say 'my bad', depending on whether they had a valid _technical_ complaint or not)."

When the same patchset arrived on the Linux Kernel mailing list from multiple sources, Christoph Hellwig asked, "any reason we've got this patchset posted by three people now? :)" Andrew Morton retorted, "presumably because I haven't been merging it." He went on to explain:

"I was in bugfix-only mode from a week prior to 2.6.24 release and during the merge window. Partly caused by the already-idiotic amount of stuff we had queued for 2.6.24, partly because we needed to concentrate on stabilising the 2.6.25 patchpile rather than writing new stuff.

"And partly to send the signal that rather than beavering away on new features all the time, we should also be spending some (more) time testing, reviewing and bugfixing the current and soon-to-be-current code. Probably I should have been more explicit about it, but it wasn't really planned. Next time I'll send more 'thanks, I parked this for consideration at a more appropriate time' emails."

With the official release of the 2.6.23 kernel expected any day now, Andrew Morton posted his -mm merge plans for the 2.6.24 kernel. The current Linux kernel development model is to open up the mainline kernel for significant merges during the two weeks following a major kernel release. Thus, during the two weeks following the imminent release of the 2.6.23 kernel, subsystem maintainers will push their latest trees to Linus' mainline tree. Andrew Morton will also push many of the patches he collects in his -mm tree to Linus' mainline tree during these two weeks, as detailed in his email. At the end of the merge window, 2.6.24-rc1 will be released and the stabilization process begins, though in reality significant merges also often slip in between -rc1 and -rc2. A series of -rc kernels will be released, eventually leading to a stable 2.6.24 kernel two or three months after the process started, and it all starts again.

A frustrated sounding Andrew Morton released the 2.6.23-rc6-mm1 kernel as "a 29MB diff against 2.6.23-rc6." Many patches are merged first into Andrew's -mm tree for testing before being pushed to Linus' mainline tree during the merge window. Andrew suggested that the -mm process wasn't working as well as it could:

"It took me over two solid days to get this lot compiling and booting on a few boxes. This required around ninety fixup patches and patch droppings. There are several bugs in here which I know of (details below) and presumably many more which I don't know of. I have to say that this just isn't working any more."

"With 2.6.24 probably opening in the not-too-distant future, it's probably a good time to review what my plans are for when the merge window opens," began Roland Dreier on the Linux Kernel mailing list. He reflected on the recent decision to phase in usage of reviewed-by tags noting that he was a little behind on reviews, "unfortunately, due to the length of the backlog and the fact that 2.6.23 seems fairly close, some of the things listed below are going to miss the 2.6.24 merge window." Roland continued, stressing the importance of getting in-depth reviews:

"Although the plan is to phase in requiring 'Reviewed-by:' gently, for this merge, if you can get someone other than me to review your work, then the chances of it being merged increase dramatically. I'm talking about a real review -- ideally, someone independent (from another company would be good) who is willing to provide a 'Reviewed-by:' line that means the reviewer has really looked at and thought about the patch. There should be a mailing list thread you can point me at where the reviewer comments on the patch and a new version of that patch addressing all comments is posted (or in exceptional cases, where the patch is perfect to start with, where the reviewer says the patch is great)."