[lkml]   [2000]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Standard Development Integration
    On Tue, 11 Jan 2000, Horst von Brand wrote:

    > Date: Tue, 11 Jan 2000 12:21:28 -0300
    > From: Horst von Brand <>
    > To: Marco Colombo <>
    > Cc: "Mike A. Harris" <>,
    > Subject: Re: Standard Development Integration
    > Marco Colombo <> said:
    > [...]
    > > There are only 2 kernels now. 2.2.xx and 2.3.xx. 2.0.xx is somewhat
    > > supported for bug fixes only, and there not much work on it, i think.
    > > When 2.4 is released, active support for 2.2.xx will be dropped anyway.
    > > So there will be only 2 kernels, 2.4.xx and 2.5.xx.
    > There are at least 3 under active development right now: 2.0.39pre, 2.2.x,

    2.0.39pre is not what i call "active development": it's still supported
    for bug fixes. I doubt any major kernel features (knfds, RAID 0.90, ext3,
    ReiserFS) will be back-ported. I'm an happy user of 2.0.38 box, i like
    having that kernel serie updated. But that's not active development,
    please. And i think no one wants it. 2.0.xx is rock-stable, and i love
    3 lines patches like 2.0.37 to 2.0.38 (or was it 5 lines? B-)).
    "Active development" means new features added, if not major kernel core
    redesign. I do hope 2.0.xx won't see that!

    > 2.3.x. It seems 1.2.13lmp development stopped, but who knows... and then
    > there are the variants from the different distributions (mostly on 2.2.x,
    > but also 2.0.x)

    It's true. That's precisely what i fear. "Variants" are good, if they
    are based on 2.3, the current DEVEL serie, like 2.3.xx-ac/aa. I'm not
    proposing any single patch to under development piece of code to go in
    one big 2.5.xx. Let developers have their own tree.
    People developed against 2.2 because 2.3 was not there,
    or because in its early patch levels it was so instable. We had about
    6 months of lack of a usabel DEVEL kernel serie (around 2.2.0). People
    have been forced to develop on 2.2.xx at that time. Later, they needed to
    test they code for stability, and 2.3.xx was not ready for that, so
    they published their patches agaist 2.2.xx again. Now, their code is
    "usable" (even Alan said that) on 2.2 and has major incompatibilities
    with 2.3, and prabably won't be in 2.4. This happaned not only with one
    "package", but with many of them (ISDN and RAID at the time of 2.0 - 2.2,
    Ext/Reiser FS now, not to mention knfsd...). See my point?

    I'm just proposing to shorten the devel cycle not by simply reducing
    the time between the first releaase of 2.5.0 and the final of 2.6.0,
    which may be a bad thing, but just letting it overlap with the previuos
    cycle of 2.3 - 2.4. Numbers means nothing in this context, but let's see
    an example. Given a devel cycle on 12 months, we have now a stable release
    every year, roughly this way:
    3 months of wild changes/core rewriting - 3 months of porting the rest
    of the kernel to the new API - 3 months making it stable - RELEASE
    3 months of fixes - SPAWN of new devel.
    I'm just proposing to have two overlapped cycles, about 6 months apart:
    just spawn the new devel when you're at the pre-release step. This way
    there's always a place to put development code, with no need to way or
    to develop against stable releases... and there's also less pressure
    on including "new" features on a nearly stable kernel.
    Yes, having two cycles means double work. But also developing against
    2.2 and then "backporting" to 2.3 is also double work...

    > --
    > Dr. Horst H. von Brand
    > Departamento de Informatica Fono: +56 32 654431
    > Universidad Tecnica Federico Santa Maria +56 32 654239
    > Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513


    ____/ ____/ /
    / / / Marco Colombo
    ___/ ___ / / Technical Manager
    / / / ESI s.r.l.
    _____/ _____/ _/

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.028 / U:5.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site