lkml.org 
[lkml]   [2005]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: Starting a stable kernel series off the 2.6 kernel
    On 12/3/05, Lee Revell <rlrevell@joe-job.com> wrote:
    > On Sat, 2005-12-03 at 20:35 +0100, Adrian Bunk wrote:
    > >
    > > But yes, what I suggest is partially a step back in a way that it
    > > doesn't conflict with the current 2.6.17+ development model.
    > >
    > > Well, if taking the best from the old style development is improving
    > > things that isn't something bad.
    >
    > You seem to be saying that the current development model is unacceptable
    > for users for whom older kernel work just fine, and the main risk in
    > upgrading is regression. But the new development model is clearly
    > needed for those users whose needs are not met by the old kernel, say
    > due to unacceptable soft RT performance or unsupported hardware.
    >
    > But it's wrong to try to evenly balance the needs of these two classes
    > of users, because the first class has another option - they can stick
    > with the old kernel that works for them. The second class of users has
    > no other option, so their needs should be given greater weight.
    >
    > Lee
    >
    > -
    > 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/
    >

    Mhhh something much simpler:

    Use the current development model between 2.6.N and 2.6.N+1. This
    means the current dev model would be used like NOW, BUT changing the
    versioning scheme in a way which reflects the 6months release plans.
    TRYING TO EXPLAIN THINGS BETTER: You could skip the version scheme
    change and do something like:

    EXAMPLE:

    2.6.14 - ok let's plan 3/4/whatever releases in the next 6 months with
    those major new features:
    - A
    - B
    - C

    then: .15, .16 like every 2.6 kernel, same dev model, same everything
    (erhm not every just like the latest releases, ok)
    .18 would be MAINLY stabilization: no device model changes, no
    networking change, and so on (but i think it would be ok new drivers
    since they cant be disabled or simply not used)

    and .19 would come out months after the .14 release

    it's not a stable/devel or 2.6/2.7 or better 2.4/2.5 scheme (even a
    2.6/2.7 scheme almost exists with main tree/-mm tree atm) or old stuff
    under a different point of view BUT it's the SAME current dev model
    applied to every release EXCEPT for the last one BEFORE the 6months
    timeline.

    what does it means: no one says nothing is unacceptable, it means
    things could be better for distros/users/external kernel projects by
    doing something that could be called a two-layers model:

    --------------------
    Linus & co. "hey, let's write down the major features for the next 6
    months and plan things a little"
    --------------------
    Other kernel developers "I would like to get in X, Y and Z. Let's do
    it 2.6.x style."
    --------------------

    The changed versioning scheme just reflects the 6months release ciclye
    idea. fullstop.

    trying to clarify again:

    > What you're suggesting sounds just like going back to the old style of
    > development where 2.<even>.x is stable, and 2.<odd>.x is development.
    > You might as well just suggest that after 2.6.16, we fork to 2.7.0, and
    > 2.6.17+ will be stable increments like we always used to do.

    every 2.6.N.x release would be the SAME as a 2.6.x release. The entire
    6months cycle puts in some time/features/stability boundaries on top
    of the existent model. Finally, those stability boundaries would be
    planned every 6months assuring the best fit of the model with
    developers, distros and users needs.


    hope I clarified,
    Michele
    -
    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/

    \
     
     \ /
      Last update: 2005-12-03 22:06    [W:4.105 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site