Re: My thoughts on the "new development model"

From: John Richard Moser (nigelenki_at_comcast.net)
Date: 10/27/04

  • Next message: Ingo Molnar: "Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3"
    Date:	Wed, 27 Oct 2004 09:38:19 -0400
    To: Willy Tarreau <willy@w.ods.org>
    
    

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Willy Tarreau wrote:
    | On Wed, Oct 27, 2004 at 12:29:10AM -0400, Rik van Riel wrote:
    |
    |>On Wed, 27 Oct 2004, Marcos D. Marado Torres wrote:
    |>
    |>
    |>>When it happened in 2.4 2.5 was created. Isn't all this just the
    |>>indication that we need a 2.6 development like 2.4 is, and we need 2.7
    |>>to be created?
    |>
    |>While a 2.7 series might provide developers with an "outlet"
    |>for their creativity, it does not give users the availability
    |>of the features they need.
    |
    |
    | Rik, "new features" are what causes the kernel to be in permanent
    development
    | mode. It happened to all of us that a new feature broke compatability
    with a
    | patch or even caused a side effect. Users don't "need" new features, they
    | *want* them.

    Strong point.

    [...]

    |
    | If you think that new features is something absolutely necessary, then we
    | could have a permanent 4-digit kernel version.

    Undue work. The current high-speed development model could be reused as
    2.7's development model. Since it's good enough to use on the stable
    tree, it can be said that 2.7 will always be stable, and so it can be
    released often. Also, distributions/users can cling to 2.7 and use it
    freely without worrying that it's an explosive dev kernel that will eat
    their hard drives.

    [...]

    |
    |
    |>Most features are developed because a user needs them now,
    |>so having the users wait until 2.8 is not acceptable.
    |
    |
    | yes it would be acceptable if 2.8 was expected only half a year from now.

    Half year release cycle, as I said in my proposal[1], using a volatile
    but usable tree (as 2.6 is now) instead of a flat out unstable tree (as
    2.5 was) for the odd majors. I think we can endure another 3 months of
    the kernel acting up like this, and then freeze it January 31 and branch
    it to 2.7 with the same behavior as it has now WRT patching and new
    features; of course, that's not my call.

    [1] http://lkml.org/lkml/2004/10/26/171

    What's important here is to keep the current development model in
    spirit. It's obviously working if you can call a very volatile tree
    "stable," so we shouldn't revert completely to stone-age methods; but
    having a defined release cycle is easy if the development trees are
    handled as 2.6 is now.

    |
    |
    |>Making
    |>the distributions backport the needed features into 2.6 leads
    |>to lots of duplicate effort and some code fragmentation.
    |
    |
    | I agree, and it also causes incompatibility between systems. I recently
    | sadly discovered that RHEL 3.0 was not "Linux" anymore, but "RHEL". With
    | all the 2.6 backports into 2.4, you cannot make it boot on a true 2.4
    | anymore. Very sad indeed.
    |

    Dude, lots of crap won't boot 2.4. Try booting Reiser4 on 2.4 (there's
    no reiser4 for 2.4).

    | Cheers,
    | Willy
    |

    - --
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.6 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFBf6TKhDd4aOud5P8RAhVCAJwMugUdGgYnezh3/ONjNQWIppuetwCfUppX
    pQfKCRw3rwFXOeJO2NtFdmg=
    =VgEV
    -----END PGP SIGNATURE-----
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Ingo Molnar: "Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.3"

    Relevant Pages

    • Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
      ... no-one apparently tested all the features together ... I pulled again on July 20 and all the bsg code was in mainline. ... The initial bsg submit went via the block git tree ... ... window git trees) and nothing else. ...
      (Linux-Kernel)
    • Re: RFD: Kernel release numbering
      ... practice, is to put "more intrusive" features into -mm first, and only ... -mm would be the 'feature tree'. ... SUSE LINUX Products GmbH - A Novell Business ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Multiple Artist Indexing Probs with WMP10
      ... now I can see three nodes in the Contributing artist tree on the left ... thing since WMP library features represent similar features to what ... > but without having to loose the autoplaylist retrieving feature? ... That gets you the union of the entries, not the desired intersection. ...
      (microsoft.public.windowsmedia.player)
    • Re: starting with 2.7
      ... but once existing features are removed there simply is ... developers' dissatisfaction with the development model has been ... > passed then the code is not ready to be included in any kernel. ... and each of the fragmented codebases gets a ...
      (Linux-Kernel)
    • Re: Yo Snarl!
      ... > Methinks a '47 offset top triple tree would've been a better/closer ... > Another thing to consider, while yer in there, is that th' new style ... I can do the holes and locate them relative to one another no ... problem but the other features are hard to get exact. ...
      (rec.motorcycles.harley)