[lkml]   [2003]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectSome thoughts about stable kernel development

    There is no doubt any development model has some problems, and ours
    can't be an exception. I'd like to share with you an idea which
    recently found a way to my mind.

    There is a problem that a development cycle (time between stable
    = non-pre/rc versions) is long. Imagine a situation when we are at
    some pre-3 stage, the kernel tree is full of problems which must be
    resolved before the final release, and some serious security-class
    bug has been found. We would be unable to have a secured stable
    version shortly unless the maintainer checks through all changes to
    last stable kernel, identify fixes which are both safe and necessary
    (hopefully there are no necessary unsafe ones at that time), and
    back-out everything else. Such a scenario is real and that way we might
    end up with official kernel being unusable for any Internet-connected
    tasks for weeks.

    Here is what I propose:
    As all of you know, the development cycle can be shortened by using
    two separate trees for a stable kernel line.

    Say, we're now at 2.4.23-rc1 stage. This "rc" kernel would also be
    known as 2.4.24-pre1. The maintainer would apply "rc"-class fixes to
    both kernels, and other patches (which can't go to "rc" kernel) would
    be applied to 2.4.24-pre1 only.

    After 2.4.23-rcX becomes final 2.4.23, the 2.4.24-preX would become
    2.4.24-rc1 and would be a base for 2.4.25-pre1.

    This way:
    - there would be no time when patches aren't accepted
    - the development cycle would be shorter. In fact it would be much
    less important as there would always be an up-to-date stable version.
    - we would avoid a mess of having two separate trees, with different
    fixes going in and out.
    - the amount of added maintainer's work is minimal, especially if patch
    authors specify which tree they want it to go in (i.e. even a small
    trivial patch would be applied to "pre" only if requested by the
    - the 2.X.Y-pre* patch would always be based on latest 2.X.Y-1-rc or
    final kernel.
    - as an option, we could go from absolute to incremental -pre and -rc
    patches: i.e. rc2 would be based on rc1 and pre2 on pre1. It would be
    easier for both disks and people (no need to patch -R).

    Of course, I know 2.4-ac patches maintained by Alan Cox fulfilled
    some (most?) of these points, even if it wasn't their primary function.

    This mail isn't about criticizing anyone nor anything, and is not only
    related to 2.4 kernel - I just try to make the development process of
    stable kernel lines a little better.

    Krzysztof Halasa, B*FH
    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-03-22 13:58    [W:0.021 / U:70.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site