Slashdot Mirror
Linux Kernel Release Numbering Revisited
An anonymous reader writes "KernelTrap has a summary of a lengthy discussion on the Linux kernel mailing list, in which Linus Torvalds has suggested using an alternative numbering scheme for kernel development. The current 2.6 kernel has been different than older development trees, as active development has been happening at a rapid rate in the officially "stable" kernel, instead of forking the expected 2.7 "development branch" for this effort. In Linus' latest proposal, he suggests using the same odd and even arrangement where an odd number signifies a development release, and an even number signifies a stable release. The difference being that this will all happen under 2.6 and thus at a much more rapid rate. For example, the upcoming 2.6.12 release would focus on fixing bugs and thus be more stable, while the following 2.6.13 release would include new functionality and thus could be less stable."
Why not add new functionality in release candidates, and only make it an official release once it's stable?
-rsw
One thing hurting Linux' credibility is that it is hard to predict volatility in it. If it works out that I would know to avoid odd 2.6.x releases, that would be very helpful.
People want everything, so obviously it's difficult to balance development against stability. This is one area where Solaris has an edge, where even though it takes longer from something to get into the commercial release, at least someone took a look at it before putting it there. Only now has GNOME made it officially into Solaris 10, but there are few issues with it, which is nice.
-- Microsoft is the most expensive commodity operating system and office suite vendor in the marketplace.
why does it matter what the versioning scheme is?
Phase 2, the -pre part of the cycle, would be where you have the stabilization and verification. It would be less a soft freeze and more a slushy, but the idea is to make sure everything works. Phase 2 finishes when Linus Torvalds is bodily hauled out of the computer room to play five-dimensional scrabble with his kids.
What you'd end up with is a release that is reasonably stable, AND YET developers would still get to increase the pace of development. You can have it both ways, provided you keep things in sync.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
This would be a good idea. I compiled 2.6.11 this morning on my laptop, and the alsa nm256 driver locks up the machine on boot :(. This has been happening on and off for some time. I found patches in the module developer's cvs that helped me fix it in 2.6.10, but apparently these didn't make it into 2.6.11 (or it got broken in some other way).
2.6 is great and there are lots of great new features and development in the kernel. But it would be good if some dot releases were only bugfix releases because right now I think 2.6 is much less reliable than late 2.4 kernels were. On my laptop this only serves to annoy me, but I run servers at work (and a webserver @ home), and right now I don't feel confident at all running newer 2.6 kernels on a production server.
No one wants to mess with a new kernel until it's stable.
The ALSA drivers were held up as an example of something that worked until it hit userland, and suddenly, ALSA was salsa on Thinkpads.
The marketing question *gasp* becomes, How do we entice users into compiling and testing on broader architectures?
Actually, Gentoo, for one, at least makes it semi-manageable to have a fistful of kernels--I may actually emerge something for fun.
(The agony of getting my 11g with WEP and nVidia all configured has been non-trivial. I still have to become root briefly and run a script when I boot, as I haven't fully grokked the 'right' way to set all of these parameters).
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Rolling your own stable kernel isn't that hard to do, especially with the resources of a distro. In fact, since one man's stable is another man's unstable, it is probably the only way to make sure that it is stable for you, which is what's important.
I maintain 3 kernels for myself: a stable, medium, and unstable. The stable kernel is a 2.4.20 with only security patches applied. (2.4.21 broke some commercial software that I use occasionally). My unstable is the latest 2.6 release. The medium is a couple of 2.6 releases back, with only security patches applied. My wife uses medium all the time. I use medium when doing something important and unstable otherwise. Once I have used an unstable kernel long enough without problems, it becomes my new medium kernel and the cycle continues.
Interestingly, the last three 2.6 releases have failed to become my medium kernel because of instabilities. Perhaps enough people are having similar experiences to prompt the rethink in process? I personally think the proposal would be an excellent compromise, and would actually fit better with how other open source projects are run.
This space intentionally left blank.
I like Linus' new proposal (and I even thought of this years ago), but I think it is mostly psychological. Bugs will be fixed in both 2.6.even and 2.6.odd releases, but with 2.6.even releases "themed" to be stabilizing bugfix releases, kernel developers will focus more on bugfixes and less on pushing out immat ure features. Plus, the 2.6.even releases will increase the rate of kernel releases, so bugs will get fixed sooner. Currently, some bug in 2.6.10 (let's say) wouldn't get fixed until 2.6.11 and users would have to wait for bug fixes AND new features to mature in 2.6.11rc pre-releases.
However, what DOES scare me is that Linus thinks (and he proves it time and time again) that HUGE kernel changes are safe within stable releases. In 2.4, he dumped the VM. In 2.6, he gave the example of switching from 3-level page tables to 4-level page tables. Linus, that is NOT a minor change!
cpeterso
In 2.6, he gave the example of switching from 3-level page tables to 4-level page tables. Linus, that is NOT a minor change!
Actually, it isn't as big a change as it sounds like. And it is something that, if it breaks will *really* blow up in a big way, not just silent data corruption for 4 people with usb asdf dongles. So it was easy to iron out the bugs in testing.