Torvalds: How to Keep Linux Kernel on Course (
Page 1 of 2 )
The progress of the Linux kernel is now focused into three developmental "trees," which balance technological progress and bug fixes. The new approach is bearing fruit, say open-source developers and founder Linus Torvalds.The rapid pace of Linux development appeared to hit a roadblock last year with the industrys decision to forestall development of the Linux 2.7 kernel. Linux vendors and developers wondered if tweaking a single, stable 2.6 kernel could
work in practice.
According to open-source insiders, the move to create separate kernel trees for technology testing and bug fixes, which are then incorporated into the stable kernel when ready, has been a huge success, pleasing both kernel developers and the vendors who distribute the open-source operating system.
"Im certainly pleased, and judging from the reactions we had at the Linux Kernel Summit in Ottawa a few weeks ago, most everybody else is too," Linus Torvalds, the founder of the Linux operating system, told eWEEK.
The biggest advantage of staying with 2.6.x was that developers do not have two different trees between which they need to port patches, which makes them happy, he said.
Linux vendors tend to like the move, because the upgrades are more gradual, rather than the huge, and potentially painful, jumps of the past.
This shift started at the 2004 Linux Kernel Summit with the decision to no longer have a separate kernel development tree, but to keep adding new features, technologies and patches to the existing 2.6 stable tree, Greg Kroah-Hartman, a Linux kernel developer with Novell, told attendees at the annual OReilly Open Source Convention last week.
That decision has spawned three separate 2.6 trees: The first is the mainline or stable kernel, known as 2.6.x and which is maintained by Torvalds; the second is known as the 2.6-mm tree, and is where technologies are tested before they get into the mainline kernel; and the third is the 2.6.x.y kernel (known as the .y kernel), which is for bug fixes only.
Click here to read more about the decision not to move to a 2.7 development tree.
The .y kernel is governed by a set of strict rules, including that the fix has to be less than 100 lines, that it applies to something already in the mainline kernel, and there had to be a three-day public review of all patches to allow all involved parties time to express their view and to make sure that everyone bought in, Kroah-Hartman said.
There were 12 2.6.11.y releases, with just 507 lines added and 303 lines removed, "which is the way to just get things fixed and I think shows that this process is working. These fixes also go into the mainline release and the 2.6.11.y was dropped when the 2.6.12 release came out. There have been four 2.6.12.y releases so far, with the latest released last Friday," he said.
The 2.6.12.y releases have had just 169 lines added and 199 lines removed.
"We are not back porting big experimental things into the .y-series," he said.
But there needed to be a mechanism for testing new technologies, a place where they could be revised, updated and even removed before actually getting into the mainline kernel.
As such, it was decided that the -mm tree would be the place where things were tested before they got into the mainline kernel, Kroah-Hartman said.
For his part, Torvalds was upbeat about the changes.
"Of course, it has led to us having to be a bit more careful about things, and the 2.6.x.y releases end up being another sign of how weve changed our process a bit as a result of this all, but I think its been an unqualified success," he told eWEEK.
These changes have significantly improved the kernel development process and have allowed the team to keep things less diverged, with people doing development off a base that is closer to what most people end up doing.
With the huge development splits required for the big rewrites under the old model, some developers had to work on both the development and the non-development kernel, which did not always please them, Torvalds said.
But he did leave the door open to create a 2.7 tree "if we hit some fundamental change that makes us split into a 2.7.x tree. We havent hit anything yet, and people seem to be doing well, but I want to point out that if something really fundamental rears its ugly head, we still accept the possibility that wed have to do a full unstable branch split."
Next Page: A flawed process.
Linux & Open Source 
