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.
I was planning on submitting a patch to make a certain tablet pass pressure data to X. (By re-mapping Tablet-Pressure to Mouse-Z).
Now I'll have to rush to get it in without a huge wait before it gets in the main tree.
Linux has made amazing progress.
But as I browse the submitters of actual code, it seems that it's no longer the every-man's operating system.
More and more often we're seeing Red Hat and IBM employees tinkering with the code.
Does this mean a lack of quality? No, certainly not. A professional developer is usually very well versed in what he or she's working on.
But I propose that we watch what is being worked on and that our priorities are appropriate.
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.
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.
Hopefully RM Stallman and friends are always heads-up, but I'm aware that often some serious fights take place on the Linux kernel mailing list regarding these types of issues.
Let's keep Linux progressing in the areas it needs to mature!
If you "get" pointers add me as a friend (116)!
I, for one, welcome our English-correcting overlords.
As long as the correction is done in a kind manner, this kind of stuff does nothing but help. I've learned a few things, at least.
More
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.
Sane input devices use XInput and help from an X driver, not remapping. And apps that understand pressure, expect Xinput devices. Just pointing that maybe your approach is far from normal.
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.
so write a driver for instance, and when it doesn't work right you hand it to someone else who has to first understand what you did in order to fix it? Seems like the original coder should be the one fixing the bugs.
Now if you mean handing it to a QA team, that sounds fine.
Jeremy
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.
Didn't Torvalds once say something along the line that 'perfect is the enemy of good' when criticizing BSD?
What linus has really said in the past:
"I retain the right to change my mind, as always. Le Linus e mobile."
"And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok"