Is the Stable Linux Kernel Moving Too Fast?

darthcamaro writes "Yesterday the stable Linux 3.10 kernel was updated twice — an error was made, forcing a quick re-issue. 'What happened was that a patch that was reported to be broken during the RC [release candidate] review process, went into the release, because I mistakenly didn't pull it out in time,' Greg Kroah-Hartman said. The whole incident however is now sparking debate on the Linux Kernel Mailing List about the speed of stable Linux kernel releases. Are they moving too fast?"

Comments

Released kernels are the real testbed

[icebike]

As indicated in the debate on LKM, rc kernels get hardly any testing, although all of the tests it does get are mostly by highly motivated and astute testers

Most distros are releasing kernels at least one behind the developers tree, with not a great deal of incentive to update the kernel right away, (even if they make it available in a repository for those wanting it). So much of the real world testing on new kernels comes only after its been released, and even then it doesn't hit Joe Sixpack's machine for several months.

So at most, this was an embarrassing incident, and not a bit deal. The amazing thing is that it was caught at all. Some of us remember kernels that got into production distros with serious things broken that should have been caught much earlier.

Re:Released kernels are the real testbed

[CAIMLAS]

From where I'm sitting, as someone who used to routinely build rc releases and use them, this is how things look.

Five, ten years ago you had people such as myself who would build RC (or AC, etc.) kernel trees to test things and see how they'd work. I know several people who regularly made LKML submissions, many of which turned out to contribute to fixes.

Today, using the rc releases isn't as practical because they're fairly divergent from distribution patchsets. A lot goes into a distribution kernel which isn't present in the vanilla kernel.org kernels, it seems.

More often than not, pulling everything together to build our own kernels isn't worth the extra effort: possibly due to the shortened cycle and possibly due to general code maturity, there's little benefit. Maybe our definitions of 'benefit' has changed, too - but arguably, the changes in the kernel today are nowhere near as drastic or significant as when (say) XFS was getting merged with additional kernel and disk schedulers.

No, you want a frozen kernel

[robmv]

No, you want a frozen kernel. A stable kernel isn't one without bugs, is one where there aren't massive changes and you get dot releases with fixes

Re:Time for an LTS Option

[greg1104]

3.10 is the next LTS kernel by Linux standards. The existing long term kernels are 2.6.32 (as used in RHEL6, Debian Squeeze, Ubuntu LTS 10.04), 2.6.34, 3.0, 3.2.50 (used in Ubuntu 12.04 LTS), and 3.4.59.

Re:TDD

[MikeBabcock]

You need to do some more reading on how Linux works.

Re:Compared to what?

[MikeBabcock]

Which would be why you should use an actual distribution kernel and not the compile-it-yourself variety if you need stability and testing.

Re:Poor version control

[andy.ruddock]

From the article :

"At 9 a.m. PT on Aug. 20, Linux kernel developer Greg Kroah-Hartman announced the 3.10.8 kernel update. At 3:44 p.m. PT, Kroah-Hartman announced the Linux 3.10.9 kernel."

So, it was a new release, not a re-release.

Re:TDD

[serviscope_minor]

You need to do some more reading on how Linux works.

So do you.

Linux is sort of a hybrid kernel now. Some hardware drivers are in ring 0. Quite a lot are no longer. libUSB for example allows userspace USB drivers. They work great. FUSE allows for user space filesystems which work great where absolute top performance is not necessary (eg sshfs, ftpfs etc).

A good fraction of the bluetooth stack, for example anything above L2CAP (the Bluetooth world equivalent of the IP stack's SCTP) , such as ATT and GATT is all userspace (and the non kernel side sucks donkey balls by the way). That means I could (if it didn't suck massive donkey balls) control all the various profiles with the majority of the code in userspace.

All the printer drivers are mostly in userspace (yay).

The graphics (X11) is largely in userspace for now...

Sound has a large userspace component and all the complex stuff like routing, mixing, and figuring out what to send where is in userspace (pulse or Jack).

The Linux kernel as-is is more than capable of running a mouse driver in userspace.