[lkml]   [2005]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: Starting a stable kernel series off the 2.6 kernel
    On Sun, 04 Dec 2005, Jesper Juhl wrote:

    > On 12/3/05, Greg KH <> wrote:
    > > On Sat, Dec 03, 2005 at 03:29:54PM +0100, Jesper Juhl wrote:
    > > >
    > > > Why can't this be done by distributors/vendors?
    > >
    > > It already is done by these people, look at the "enterprise" Linux
    > > distributions and their 5 years of maintance (or whatever the number
    > > is.)
    > >
    > > If people/customers want stability, they already have this option.
    > >
    > Yes, I know this is what's done with the "enterprise" distro kernels.
    > Perhaps I should have phrased it "Why can't this job just stay with
    > vendors".

    Because this is just shifting the blame for and work to make up for the
    upstream not providing a stable tree on somebody else and prescinds from
    the fact that many people are apparently unhappy with 2.6.X policies.

    I cannot see a project issuing "stable releases" if every other
    developer bleats "let the distro snapshot and backport fixes on their
    own". This is exactly the point that turns away half of those who hadn't
    been scared away by the "Linux has no uniform userland" problem yet.

    2.6.0 is now nearly two years old, perhaps the current discussions mean
    that 2.7/2.8 are long overdue - some people feel the need for more
    radical code changes, which are 2.7 stuff.

    The problem is the upstream breaking backwards compatibility for no good
    reason. This can sometimes be a genuine unintended regression (aka.
    bug), but quite often this is deliberate breakage because someone wants
    to get rid of cruft. While the motivation is sound, breaking between
    2.6.N and 2.6.M must stop.

    One of the ideas of the new development style and versioning scheme was
    to have 2.6 progress faster than 2.3 or 2.5, and to have shorter release
    cycles. It was found to introduce way too much breakage. Linus's
    relatively new policy "merge new stuff only during the fortnight after
    release, then fix up" is a concession to these observations that too
    many things break if there is a constant influx of feature changes.

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

     \ /
      Last update: 2005-12-04 13:01    [W:0.021 / U:2.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site