Built to last

It has now been almost exactly five years since kernel development community tentatively started using the git source code management system with the 2.6.12-rc2 commit. That was an uncertain time; nobody really knew how long it would take the development process to get back up to speed after an abrupt core-tool change. As it turned out, git was almost immediately useful, and has only become more so since. Making the development process work is git’s main claim to fame, but, as a side benefit, git also makes it possible to learn a lot about how our kernel is developed. And that, as it turns out, includes taking a look at the code which is not changed.

The speed of the development process is impressive; the nearly-released 2.6.33 kernel is the product of nearly 11,000 individual changes affecting nearly a million lines of code (look here for more 2.6.33 statistics). Those numbers are boringly normal for a three-month development cycle; things are always moving that fast.

Given that, one might think that, by now, very little of that 2.6.12-rc2 kernel which was first committed to git would remain. After all, over 500,000 lines were deleted in this development cycle alone. I got curious, and decided to look a bit deeper. The result was the creation of some brutally hackish Python scripts, the expenditure of about a week of solid CPU time, and some statistics on the age of the kernel code base. Continue reading.

Hola! Looking for an answer to a question but did not find it? Then surf on over to the Questions & Answers section. It's a brand new addition to our site, and we are waiting just to answer your question(s).