Slashdot Mirror
New Linux Kernel Development Process
An anonymous reader writes "Releasing the 2.6.13-rc4 Linux Kernel, Linus Torvalds announced an improved development process to try and minimize the number of bugs in the kernel. The general idea is simple: changes will only be allowed for two weeks after the release of a stable kernel. All the rest of the time between releases will be spent on fixing bugs. This should improve upon last year's development module, which allows for active development in the 2.6 stable kernel."
I'm assuming (and hoping) the parent and grandparent are trolls because the kernel is already modular and your server shouldn't have audio drivers compiled in unless you're an idiot. It isn't difficult to only compile in drivers for the specific system the kernel will be running on.
They used to do this. Odd kernel releases were development/experimental, even releases were stable/bug fix. That's why the kernel went from 2.0 to 2.2 to 2.4 to 2.6. Recently in the 2.6 branch though, they moved away from that model. Don't remember why.
With all due respect, Red Hat has been the largest kernel contributor for just under a decade now. They've been taking it in a good direction so far, I wouldn't worry about it too much. Despite all the nonsense slashdotters will say about Red Hat, Red Hat is one of the few distros that actually develops the software it ships rather than just repackaging other people's software. Look at Apache, the Kernel, Gnome, libc, the GNU compiler collection, openoffice, evince, totem, dbus, and most of the drivers you use in your system. The list could literally go on for ages. They also are a major reason why linux has an amazing record for getting patches out quickly for security fixes, alot of those fixes are coded by Red Hat develoeprs. Not to mention they gave Linus 10 million dollars in stock as a showing of gratitude to him. They are a good company, and some of the best kernel hackers are paid by them (including Alan Cox).
Regards,
Steve
Also note that they are going to try this approach. If it doesn't work out, I expect that Linus (ever the pragmatist) will drop it rather quickly...
This simply makes it so that bug patches don't get stepped on all of the time. Developers that are submitting feature updates will have to simply time their submittion. I don't think it'll slow development at all, it'll just polish releases more easily.
Except he is wrong. Many (like Tolkien, a philologist) spoke in favour of 'and' in this case.
There's no reason to test the patch with 2.6.13 (as opposed to 2.6.13-rc4) if you're trying to get it into 2.6.14; there's a much higher chance that something will break it between 2.6.13 and 2.6.14-rc1 than between 2.6.13-rc4 and 2.6.13, since the former is when all of the new features are getting put in, and the latter is only the last set of bug fixes during a code freeze. The point of the change is so that you're not the only person testing it in the cycle leading up to the release that includes it, because bugs will probably show up in configurations you don't have.
Of course, the right way to get a change made is to get it into -mm now (or whenever), and have it working there; then it'll get tested and accounted for in other development, and will get put in by default at the start of the cycle if there's been good feedback. Then you just have to test it in -rcs and report if it gets broken.