Earlier, I had discussed why changes to the Linux kernel development model were needed to better support third party development. Now I feel it's time to sit down and discuss what key issues the current development model raises.
I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner.
While all patches added to the kernel are considered to be in their stable release cycle, stable releases always have lurking bugs. With the widespread use of mainstream release, software is put through testing several orders of magnitude more rigorous than its beta releases or smallscale stable release. This almost always brings the exposure of existing but previously unnoticed bugs.
Security flaws are bugs. Some bugs are memory corruption bugs or information leaking bugs, which can create a situation where confidential information is accessable by non-privileged users. Because of the current Linux 2.6 development model, more bugs are predictably introduced into mainline, and more security holes with them.
Maintaining a truly stable series would continuously decay the number of bugs in that series. This would give vendors and consumers a viable option for a more stable and more secure codebase, rather than one in which updating to get bugfixes may involve encountering new bugs. Maintaining a series in which only bugfixes are allowed may be low enough maintainer overhead to allow several stable series to be supported, creating a long support cycle.
With a scheme in which the odd-major development series (2.7, 2.9, etc) were managed in the exact same way as the current 2.6 series is now, widespread use of the development or "Volatile" series would still be likely, as it would be stable enough for desktop use in many cases. This would facilitate the widespread use of a continuously evolving series, and contribute to the decay of the bug count.
Linus supports third party kernel development. In a conversation on the Linux Kernel Mailing List, Linus points out that he likes that different vendors have different objectives, and that they implement them in their own way:
I just think that forking at some levels is _good_. I like the fact that different vendors have different objectives, and that there are things like Immunix and PaX etc around.
The current 2.6 development model conflicts with this, however. Changing core functionality and APIs can stall the development of some third party patches. PaX, for example, was stalled on 2.6.7, and didn't have testing patches until just before 2.6.10 was released.
With a truly stable series, core functionality and APIs would remain constant for a predictable cycle. This would allow developers to focus on developing their product and not chasing a volatile codebase because of bugs and security flaws. Third party development could occur more rapidly this way; major up-porting would not have to be done for each minor release of the kernel.
Third party projects aiming for mainline inclusion would still have to track the development branch. These projects could still deffer that stress until they had a ready product for mainline inclusion.
Andres Salomon has announced the 2.6-as series to the LKML. This series supports 2.6.x kernels for a limited time with periodic 2.6.x-as(y) releases. These releases will contain bugfixes and security fixes only, and especially not driver updates, large subsystem fixes, and cleanups.
Salomon can only support a limited number of kernels. Because there is generally a new release every 1-2 months, a short support cycle is covered by the -as series. Salomon has said he is willing to accept patches from distribution maintainers to continue to support older series for long periods; however, he won't be actively searching for and backporting security fix patches for more than two or three kernels. One man can only do so much.
It can be argued that the 2.6 model is a step forward rather than a step back, despite its criticism. I believe this is true. The 2.6 development model shows the evolution of the Linux kernel's development scheme into a more efficient form which more rapidly brings new innovations and new development to the user.
Whereas the old model used to create and horribly break a development branch, then spend several months to a year trying to fix it before release; the current 2.6 model merges only working code, producing a constantly progressing but usable codebase. I believe that the further evolution of moving this growth back into a development or "Volatile" branch will bring a better balance to the process without sacrificing its current raw efficiency.