Slashdot Mirror


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

5 of 156 comments (clear)

  1. No by Stumbles · · Score: 5, Insightful

    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.

    --
    My karma is not a Chameleon.
  2. Compared to what? by bmo · · Score: 5, Insightful

    "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

  3. Re:TDD by greg1104 · · Score: 4, Insightful

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

  4. Re:What a stupid question. by Rich0 · · Score: 4, Insightful

    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).

  5. Re:TDD by The_Wilschon · · Score: 4, Insightful

    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.

    --
    SIGSEGV caught, terminating

    wait... not that kind of sig.