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?"

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.

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" [youtube.com] --Greg Kroah Hartman

I work on PostgreSQL, and nothing goes out until it's been validated on the entire buildfarm [postgresql.org]. 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.

Too Fast?

[Jeremiah Cornelius]

Let me try and catch up to it, and ask...

Seriously. Why is this even a question? Did a new stable release show up in your watch or your laptop - or your in flight entertainment system, over night?

Packagers and distribution maintainers aren't exactly up in arms about this...

What's good.

[dutchwhizzman]

Why do you have to compare it to other operating systems? Just look at what should be the right way to do it, maybe learn from other operating systems, but don't just look at the speed of what others are doing and try and match that. If things go wrong because you're moving too fast, you should either slow down, or fix your methodology so you can deal with the speed. If things don't get adapted by distributions because it's a pain to keep supporting, slow down, or make it easier for them to support it. If things go too slow and you miss essential features that everybody needs, speed it up. It's not that hard to rely on your own merits and not be dependent on other operating systems to determine how fast you should be going.

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:TDD

[ultranova]

We can't emulate every mouse, network driver, etc, so there's no way to test those drivers (which are part of the kernel).

Which rises question of just why are they part of the kernel? Why does a mouse driver need to run at Ring 0?

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.