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.
Which is also, btw, what people say they want from MS and Windows.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
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.
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.
Linus says a lot of things. It seems to me that he is just using the scientific approach, and trying new ways of doing stuff to see what works best. Some ideas are good, others are bad. But if you never change your process, you'll never find out.
These changes in the process make a lot of people scream whenever they happen. That's because people doesn't like change. Even now, people are screaming about breaking the odd/even process (which didn't work too well), even though the 2.6 process has worked much better. If the 2.6.13 process isn't even better, Linus will scrap it and try something else (such as going back to the old 2.6 process, or the 2.6.x.y process, or something else new, or whatever).
Stay calm! The world isn't going to end! All these changes mostly affects kernel developers, and even then, mostly those in the "inner circle". Your redhat/ubuntu/suse/whatever will still work just fine.
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