Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Linux Kernel Development Process

Posted by Zonk on from the working-better-together dept.

An anonymous reader writes "Releasing the 2.6.13-rc4 Linux Kernel, Linus Torvalds announced an improved development process to try and minimize the number of bugs in the kernel. The general idea is simple: changes will only be allowed for two weeks after the release of a stable kernel. All the rest of the time between releases will be spent on fixing bugs. This should improve upon last year's development module, which allows for active development in the 2.6 stable kernel."

6 of 207 comments (clear)

  1. Good because... by samjam · · Score: 3, Interesting

    It means the longer you wait, the more stable the kernel will be.

    No more lucky dips, and less need to depend on the vendors tracked patchsets.

    Sam

    --
    blog.sam.liddicott.com
  2. One concept I heard that I kind of like... by Sheetrock · · Score: 3, Interesting
    Is the idea of splitting kernel releases into two branches -- one stable, one development. This gives the benefit of allowing bugfixes to be applied to an otherwise stable tree while creating an experimental environment for new ideas, mirroring the "parallel deployment" methodology system analysts prefer for stability during upgrades (where you continue running an old system for a while after the new system is deployed so you have something to fall back on.)

    This seems to work successfully for a number of open source projects, which use a version numbering system that allows users to tell at a glance whether they're using a development version.

    --

    Try not. Do or do not, there is no try.
    -- Dr. Spock, stardate 2822-3.




  3. a philosophical contradiction? by jesuscyborg · · Score: 5, Interesting

    Didn't Torvalds once say something along the line that 'perfect is the enemy of good' when criticizing BSD? Is he moving away from 'good-enough' with lots of features constantly coming out, towards a more BSD-esque, move along slowly with stable-code philosophy?

  4. My gut tells me this is a bit extreme by Work+Account · · Score: 5, Interesting

    As I think more about this decision, I wonder why not simply split the development between bug fixes and feature providers.

    For example, Linux kernel 2.7 is released.

    We run regression test on it for a week or two.

    At that point, we document all known bugs and hand them and the entire 2.7 codebase off to our bug fixing team.

    Then we identify improvements to current capabilities as well as new features we want to add, document all of it clearly, and hand that off to the feature team along with their own copy of the 2.7 baseline.

    Then we have our bug guys working the 2.7_bugfix baseline and our features guys adding valuable new code to the 2.7_features baseline.

    Prior to the next release, we merge all the changes together, spend a week sorting out any dependecy problems and interface problems, then we ship.

    And repeat.

    Sounds feasible to me. I just don't like the feeling I get when thinking that there's such a short development window.

    The Linux kernel is already pretty darn stable, especially when compared to other operating systems. Let's keep the new features coming!

    --

    If you "get" pointers add me as a friend (116)!
  5. Re:2 Weeks by sloanster · · Score: 4, Interesting

    I think you misunderstood the concept. A developer doesn't have 2 weeks to insert new functionality. A developer can work on enhanced performance or new features for 9 months, but there is a 2-week window after each release in which patches will be accepted.

    The two things are orthogonal. Once the code has been thoroughly tested and a patch is ready it should be no problem for the core developers to email the patches to Mr Torvalds within that 2-week window of opportunity. I see no problem here.

  6. This is GREAT news by rc.loco · · Score: 5, Interesting


    I remember when the Linux kernel was rock solid, stable and reliable. I remember when there were no huge code changes in the "stable" even-numbered kernel series. Remember those days? I'm talking late 2.2.x before the whole VM debacle in the first part of 2.4.x.

    In the last few years, it seems the push to carve out marketshare on the desktop has been fuelling kernel development more so than server-oriented work. I've been frustrated to the point of recommending Linux-kernel-based systems only with caution and caveats, preferring instead Solaris for serious enterprise-level server-side work.

    If this works out, it'd be a boon for enterprise adoption of the Linux kernel. Hats off to Linus et al. for this change in their practices.

    --
    --rc