lkml.org 
[lkml]   [2005]   [Dec]   [5]   [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 Mon, Dec 05, 2005 at 11:55:36AM +0100, Lars Marowsky-Bree wrote:
    > On 2005-12-05T07:26:09, Willy Tarreau <willy@w.ods.org> wrote:
    >
    > > What I think should be done is to still maintain older 2.6
    > > (eg: 2, 3 or 4 previous releases) so that people will have
    > > the time to switch to a new one. And I think that what Adrian
    > > wants to do would be useful *only* if he proceeds that way.
    > >
    > > Maybe you should just join forces, eg Chris and you to catch
    > > new patches, and Adrian to merge them to older kernels ? Every
    > > software maker always supports a few older releases for the
    > > people who need to stay on something stable, and it is clearly
    > > what is missing now in 2.6.
    >
    > Well, this is probably the most useful suggestion so far. The kernel is
    > free land; if you or someone else wants to maintain the upcoming 2.6.16
    > "forever", and backport fixes or selected features, by all means, do it.
    > Define your policy, set up a tree, and off you go.
    >
    > If Adrian will maintain it, it'll for sure be the most static kernel
    > ever.
    >
    > This won't impact the Linux kernel, which will just continue to run its
    > course. The kernel process as a whole doesn't need to change; just
    > someone needs to do the grunt work.
    >
    > If your kernel is wildly successful and adopted by users as well as
    > distributions, you'll be very happy and tell us 'told ya so!'. If not,
    > no harm will be done either, and you'll have the kernel you want for
    > your own purposes.
    >
    > Be aware however that this is a very painful job. Trust me, I've been
    > involved with the receiving end of maintaining such a kernel for SLES
    > for a couple of releases. ;-)
    >
    > Which is exactly the point: it's so painful that for this, people want
    > to be paid, and don't like doing it in their spare time. You may
    > maintain it for 6 months, sure, which will be less painful than
    > maintaining it for 5, 7 years, but when you rebase, you'll still put
    > your users into the dependency hell, and they won't have tested the
    > intermediate releases... Ouch. Not to mention that not every backported
    > fix is trivial to do.
    >
    > Anyway, good luck to you.
    >
    > The current 2.6.x.y-stable series is quite sane, because they are
    > essentially just fixing very critical bugs in very recent kernels, with
    > little back porting effort.

    I agree it is sane. The problem is that it does not exist for long enough.
    When you have 2.6.14.X working perfectly and you need a fix for a newly
    discovered security fix which only exists in 2.6.15.Y, then you have to
    leave 2.6.14 and enter 2.6.15. That is the problem, because for just a
    fix, you change megabytes of source code which will bring their equivalent
    in bugs.

    Regards,
    willy

    -
    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-05 12:42    [W:4.098 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site