"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)."
"If you don't see an ethical problem in removing a working driver which is not taking support resources, in order to force people to test and debug a driver they don't now and never would need, so that it might in time offer them the same functionality those users already had... then I can never make you see why technological extortion is evil."
"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.
"We've gone and made it awfully easy to get code into the kernel nowadays. Perhaps too easy. I'm presently having a little campaign of watching what's going on a bit more closely, and encouraging people to make it easier for others to see what's going on, should they choose to do so."
"[The] lkml is the right mailing list for reporting Linux bugs. This is an extremely harmful trend I've seen lately: some kernel hackers going out on a limb directing the flow of bugreports _away_ from lkml, by suggesting to testers that lkml is somehow inappropriate for reporting Linux kernel bugs."
"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 :)"
"It's hard to overemphasise how out-of-balance the economics are here. You saved maybe thirty person-seconds by skipping the review and checkpatch steps. But the cost (if this bug had gone into mainline) would be many many thousands times higher than this."
"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."
"It took five solid hours to get this lot vaguely compiling. 20-30 fix patches needed, several trees dropped, 5-10 patches dropped. It is an altogether unimpressive performance."
"Unless I'm missing something, your request for revert was pretty rude, technically incorrect and you also tried to circumvent the normal course of discussion."
"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)."