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."
Proper English is:
try to minimize
not:
try and minimize
I'm just going for my dialy troll mod, since I seem to be getting many troll and overrated mods for posts that don't deserve them.
This has been discussed many times. You can configure your kernel to omit sound, v4l, etc. Even if you do compile these things, they won't be included in your running kernel unless you load the modules.
What you want can be done by removing sound and other desktop stuff from the startup services. Most distros have a friendly way to do this. No kernel recompile necessary.
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.
See the second link in the summary. Linus and others decided that getting new features integrated was more important than having a perfectly stable kernel. Andrew Morton's patchset (-mm) can be considered the development kernel.
LOAD "SIG",8,1
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
Recently in the 2.6 branch though, they moved away from that model. Don't remember why.
It was supposed to decrease the amount of backporting, and increase the available testing.
First, as new features (and drivers) were added to the development tree, people backported them to the stable branch, this supposedly drew efforts away from the development tree (ie. people were spending time backporting the new features/drivers when they could be debugging/testing the development tree instead.)
Second, as the development tree is the "stable" tree, there are more users to test it to see if things break (which is good if you're a kernel developer, but bad if you're a regular user and a kernel update breaks your server.) It was argued that as distributions typically supply and test their own kernel that the benefit it gave to the kernel devs outweighed the problems that regular users would see.
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.
So you think the the first 2.6.x.y release, which is a bug/security fix release, is less stable than 2.6.x? I think you need to review what the 2.6.x.y releases are for.
Except he is wrong. Many (like Tolkien, a philologist) spoke in favour of 'and' in this case.
I have them turned off and I didn't see his add. It also makes slashdot a hair less annoying.
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.
Actually there are a couple of basic facts to mitigate the concerns you cite above:
First of all, the developers tend to have really good communication among themselves, they know each other, and the developers know what other developers are working on. Some random john doe who appears out of the blue one day with a huge patch is not about to get his work accepted. It's also common sense to submit a patch against the current tree, not something from 13 versions ago.
Secondly, Linus uses a system to manage all these potentially conflicting changes. (For several years until just recently, bitkeeper was used to manage patches to the kernel tree - now that function is being filled by a tool called git, a version control system developed by Mr Torvalds)
In any case, these things have been thought through.
when someone trolls and notes that they'll get "unfairly" moderated for it, the usual response is "informative" . . . whehter it's trollish, informative, both, or neither . . .
hawk