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."
This seems to put more pressure on individual distro vendors to add features and test them, then discuss their inclusion in the upstream kernel. Seems pretty reasonable to me. This should definitely stabilize the kernel a lot.
It means the longer you wait, the more stable the kernel will be.
No more lucky dips, and less need to depend on the vendors tracked patchsets.
Sam
blog.sam.liddicott.com
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.
This seems to work successfully for a number of open source projects, which use a version numbering system that allows users to tell at a glance whether they're using a development version.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Didn't Torvalds once say something along the line that 'perfect is the enemy of good' when criticizing BSD? Is he moving away from 'good-enough' with lots of features constantly coming out, towards a more BSD-esque, move along slowly with stable-code philosophy?
that's a remarkably verbose post saying... what again? nothing? right.
As I think more about this decision, I wonder why not simply split the development between bug fixes and feature providers.
For example, Linux kernel 2.7 is released.
We run regression test on it for a week or two.
At that point, we document all known bugs and hand them and the entire 2.7 codebase off to our bug fixing team.
Then we identify improvements to current capabilities as well as new features we want to add, document all of it clearly, and hand that off to the feature team along with their own copy of the 2.7 baseline.
Then we have our bug guys working the 2.7_bugfix baseline and our features guys adding valuable new code to the 2.7_features baseline.
Prior to the next release, we merge all the changes together, spend a week sorting out any dependecy problems and interface problems, then we ship.
And repeat.
Sounds feasible to me. I just don't like the feeling I get when thinking that there's such a short development window.
The Linux kernel is already pretty darn stable, especially when compared to other operating systems. Let's keep the new features coming!
If you "get" pointers add me as a friend (116)!
I think you misunderstood the concept. A developer doesn't have 2 weeks to insert new functionality. A developer can work on enhanced performance or new features for 9 months, but there is a 2-week window after each release in which patches will be accepted.
The two things are orthogonal. Once the code has been thoroughly tested and a patch is ready it should be no problem for the core developers to email the patches to Mr Torvalds within that 2-week window of opportunity. I see no problem here.
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
Mods love that sort of stuff, especially when it's double-spaced, one sentence per paragraph.
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.
Perhaps an IBM or similar company has a new feature that they want, or worse, need, in the Linux kernel, and as such they spend all their time working on that.
The reality might be however that an improved VM is needed but all the Red Hat guys are busy working on some scheduling code that really isn't as crucial.
If an improved VM is needed, then who needs it? Why would there not be anybody to "scratch that itch" if people need it? The presence of large companies contributing scheduling code does not mean that other people can't contribute VM code.
But I propose that we watch what is being worked on and that our priorities are appropriate.
From your post, I suspect what you mean is that you want Redhat's priorities to be appropriate for your needs. Free Software isn't about getting other people to do what you want.
If there's nobody contributing code that satisfies your needs, then perhaps the rest of the world doesn't consider it as necessary as you do, in which case, you have an unusual problem and you know exactly what you can do to fix it - code it yourself or pay somebody else to.
As far as I know, Linus himself still verifies all submissions and deems which baselines they appear in, but I hope that since he's also a professional and getting paid by Corporate if our priorities are straight.
That sentence doesn't make sense.
How about fixing the bugs that have been outstanding for well over a year?
It really is disappointing to spend hours testing and finding how to 100% reproduce bugs, even those that freeze the system as a user, report it to the various mailing lists, only for them to be ignored.
Yes, I've tried fixing some myself.
A developer doesn't have 2 weeks to insert new functionality. A developer can work on enhanced performance or new features for 9 months, but there is a 2-week window after each release in which patches will be accepted.
The two things are orthogonal.
We'd better hope everyone's patches are orthogonal too. If five Linux kernel developers all spend 9 months working independently on patches which turn out to make conflicting changes to the same subsystems, then after 2 weeks there will be one happy developer with his patch in the Linux kernel and four unhappy developers deciding whether to fork Linux or switch to FreeBSD.
Of course, to avoid such problems we can assume that those many different kernel developers are not working independently, but are committing changes to a single unstable kernel to share those changes and prevent conflicts. In that case, let's just call the new unstable kernel "2.7" and return to the system that was working so well for years.
Except he is wrong. Many (like Tolkien, a philologist) spoke in favour of 'and' in this case.
2.6 has been one big regression fest, and despite its advantages I've always had to use something else for anything but desktop duty because the risk was too high.
There has to be a tradeoff between new features and sufficient stability to contemplate using the new features -- they aren't an advantage if they are inseparable from the bugs.
Glad Linus came around.
I rarely criticize things I don't care about.
That has been always true, and all^Wmost of linux 2.6 features are there because vendors needed it - NTPL, SMP scalability...
It's no different than any other open source project. If I want something in slashcode, I code it according to my interests. In linux, big features are coded according with the interest of vendors. There's not a really big difference. Look at the poor state of graphic drivers in linux for example - if that was important for vendors we'd have great graphic drivers
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.
I remember when the Linux kernel was rock solid, stable and reliable. I remember when there were no huge code changes in the "stable" even-numbered kernel series. Remember those days? I'm talking late 2.2.x before the whole VM debacle in the first part of 2.4.x.
In the last few years, it seems the push to carve out marketshare on the desktop has been fuelling kernel development more so than server-oriented work. I've been frustrated to the point of recommending Linux-kernel-based systems only with caution and caveats, preferring instead Solaris for serious enterprise-level server-side work.
If this works out, it'd be a boon for enterprise adoption of the Linux kernel. Hats off to Linus et al. for this change in their practices.
--rc