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

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.

Test-driven development is not the solution to this problem. And my good gawd, behavior-driven development is even farther away from the solution than fucking test-driven development is.

Behavior-driven development is one of the biggest loads of shit to splash upon our profession in years. Customers and analysts will write tests? Riiiiiiiiiiiiight...

All that we get from BDD is half-arsed tests that don't work and clients or analysts who cry to high heaven about how they hate writing them. And we programmers can't just rewrite them in Java or C# or Python or C++ or whatever our project is using. Noooooooo! They all require stupid English-like syntaxes that need to be translated down into real code by some turdy tool named after a vegetable.

Fuck TDD. Fuck BDD twice over. And please, for the love of all that is good, NEVER suggest that either of them be used seriously, especially for a critical piece of software like the Linux kernel.

Re:No

[CAIMLAS]

Really?

The current process resulted in us having CFQ + EXT3 as the default for a long time (some distros still have this). This basically means any sort of interactive performance is worse than horrible. The only reason we're beyond it now is because EXT3 is on its way out with EXT4 being preferred.

IIRC, wasn't CFQ one of the first major infrastructural things put into 'stable' after this 'rapid release' approach was adopted?

Also, udev.

I'm sure there are other examples... and maybe I'm projecting a bit.

Re:TDD

[greg1104]

The logs of the machines that break are the most important part of the test results here. You can't just throw them away when a VM dies without losing most of the testing value. If you're lucky, a busted kernel will stay alive long enough to create a crash dump when running on dedicated hardware. That's less likely to happen on VMs.

It's also possible to automate hardware resets with IPMI [wikipedia.org] or similar lights-out management code. All of that takes special hardware though, and test code like this is painful to build.

Re: No

[Brien Coffield]

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.

Re:No

[jhol13]

Linux (the kernel) is accumulating new security holes at least at the same speed as they are fixed.
Proof: Ubuntu kernel security hole fix rate has been constant for years.

(actually I have not counted the actual number of holes, only the actual number of kernel security patches - these two should correlate though).