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

No

[Stumbles]

its moving along just fine. People make mistakes, get over it, its not the end of the world. Considering its current release speed, the amount of changes made over the long term the Linux kernel folks have as good or better track record than most other software houses.

Re: No

[coffbr01]

I prefer to think that an immediate response from the community is a sign of an active and concerned user base. It might be worse if the community insisted on staying on LTS-type releases.

Compared to what?

[bmo]

"Are they moving too fast?""

Compared to what, Windows, IOS, OSX, What?

>known bug that got by review
>caught
>fixed rapidly instead of waiting for the next release

I don't see the problem.

If this was a regular occurrence, yeah, it'd be a problem. But it's infrequent enough to be "news."

Unlike Patch Tuesdays, which aren't.

--
BMO

Re:TDD

[greg1104]

"the fun thing about a kernel is that there is no good way to test it except to run it" --Greg Kroah Hartman

I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm. It's hard to have such a thing for the Linux kernel though, because it's so easy for a bug to break test machines. You need to catch when machines are responding, do a hardware reset, and then rollback to a known good kernel instead. It's much harder than most software testing to automate.

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.

That's what he said!

[fizzup]

I mistakenly didn't pull it out in time.

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:WHAT THE FUCK! WHAT THE FUCK!!!

[Anonymous Coward]

WHAT THE FUCK!

I can't believe this. I've been reading Slashdot since 1998, and I have never seen such a stupid suggestion in all that time.

...

OK, one of those two must be blatantly false.

Re:WHAT THE FUCK! WHAT THE FUCK!!!

[Motard]

Thanks Linus, but I think it's an established rule that you can't go releasing new versions of software until the ridicule surrounding your last release has died down. How else are we going to get stories for /.? Microsoft plays along. Why can't you?

Re:What a stupid question.

[Rich0]

Ah yeah, like kernel.org isn't trusted. Yes I know you said "distribution" but really now.

He wasn't talking about trusting that it didn't contain a trojan or something. By trust he meant vetted for quality.

It is a legitimate concern. The whole reason for having a release cycle is to have sufficient QA to prevent issues like this from happening. Distros provide that service - when Linus/Greg call a kernel done, they call it ready to start being tested. RHEL is still running 2.6 (albeit with backports).

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:WHAT THE FUCK! WHAT THE FUCK!!!

[Zeromous]

Only said fuck four times not including subject. Not Linus.

Re:TDD

[The_Wilschon]

For the purpose of release testing, though, the only thing you care about is whether or not there was a crash. If there was a crash, don't release. Back out the busted patch and release the working version. Then you can spend your time debugging the busted patch, which requires the logs and all.

Re:TDD

[MikeBabcock]

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

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.