Kernel 2.6.12 Released

Mad Merlin writes "Linux kernel 2.6.12 has been released! Kerneltrap has a brief summary on it. The changelog is only partial however: 'The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory. The file that says ChangeLog-2.6.12 only contains the stuff from -rc2 onward.' As always you can find the changelog and the source at kernel.org"

Comments

One thing I'm a bit confused about...

[Sheetrock]

When and why did they stop the system of releasing stable versions on the even minor releases (2.4.x, 2.6.x, etc.) and unstable/development versions on the odd minor releases (2.5.x, 2.7.x, etc.)?

Re:One thing I'm a bit confused about...

[iabervon]

The problem was that starting an unstable series was exactly the kind of fork that causes problems with development. There was a substantial period when the functionality needed to run a system with recent software and on recent hardware was only in the unstable one of the official series, and was backported to the nominally stable series by each distro individually separately and to different degrees. Furthermore, there was constant pressure to add new features to the officially stable series, rather than to the unstable series (or backported from the unstable series).

The central problem was that series progressed from unstable to stable to obsolescent to non-functioning. The solution is to always have a place for unstable features (the -mm series) and a place for stable features (the mainline series), and features move into the stable series as they become stable, rather than requiring a major upheaval and years of fussing. Then there needs to be something that corresponds to the period where mistakes in a release are fixed in a release that doesn't include anything else, even new features which are extensively tested; this is only useful until there are no known regressions in the next version with added features.

The reason that the numbering changed is that, were the numbering maintained, the recent releases would now be 2.16.11, 2.18.0, and 2.19.0 (assuming that the new system was adopted at 2.6.6, the old numbering would make what was 2.6.7 into 2.8.0, and so forth, replacing one point release with two minors, which would just be silly). Also, it would be confusing if 2.17.x included stuff that wasn't in 2.18.0, was in 2.19.0, and was in 2.20.0; this is what happens to anything that's still in testing when a release is made and then stabilizes. Since there's always stuff in testing, no stable release could ever be made without having the existance of features be confusingly non-continguous.

In any case, 2.6.x.y is now about as stable as 2.4.x was during the period before distros started moving to 2.6.

Re:Linux+OpenSolaris

[Arker]

Does anyone think there will be anything benificial to linux to borrow from solaris now that the source is out, or does their license even allow this?

Short answer: No, and no.

Longer answer, while there are a few places Solaris still has an advantage, you can't just rip code out of one and stick it another. The structure of the code is quite different, so an implementation in one codebase just won't transfer to another cleanly.

And two, the CDDL, besides being horridly written, is clearly and intentionally not GPL compatible, so even if you could transplant code like that technically, it wouldn't work legally.

Maybe?

[Saeed al-Sahaf]

Could this be part of the reason hardware manufacturers don't put a high priority for Linux drivers?

Poor Linus

[RickPartin]

Sorry about being off-topic but I've been thinking, since Linus is a normal guy and not some super human CEO, he must go through a "family tech support guy" hell that only exists in only our darkest of nightmares. I pity him.

Re:You're Fired

[slavemowgli]

There is no release manager. A new kernel gets published when Linus decides it's time; in a way, that makes him the release manager, but it's not really managing as in "creating schedules, specifications, requirements, deadlines and all that". And I at least would rather see him do actual work instead of meeting arbitrary requirements imposed on him by the more marketing-oriented types.

That being said, Linus *has* given a reason why there's no full changelog this *one* time (it's reproduced right above in this very Slashdot discussion, for example); if anyone has issues with that, I assume they're more than welcome to create a full one and post that. If noone does... well, then the itch probably wasn't worth scratching after all.

So there. If it really matters to you, then go and create a full changelog. If it's not worth your time and effort, why do you complain that Linus feels the same way?