[lkml]   [2004]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: new dev model (was Re: Default cache_hot_time value back to 10ms)
    Jeff Garzik <> wrote:
    > Andrew Morton wrote:
    > > Nick Piggin <> wrote:
    > >
    > >>Any thoughts about making -rc's into -pre's, and doing real -rc's?
    > >
    > >
    > > I think what we have is OK. The idea is that once 2.6.9 is released we
    > > merge up all the well-tested code which is sitting in various trees and has
    > > been under test for a few weeks. As soon as all that well-tested code is
    > > merged, we go into -rc. So we're pipelining the development of 2.6.10 code
    > > with the stabilisation of 2.6.9.
    > >
    > > If someone goes and develops *new* code after the release of, say, 2.6.9
    > > then tough tittie, it's too late for 2.6.9: we don't want new code - we
    > > want old-n-tested code. So your typed-in-after-2.6.9 code goes into
    > > 2.6.11.
    > >
    > > That's the theory anyway. If it means that it takes a long time to get
    > This is damned frustrating :( Reality is _far_ divorced from what you
    > just described.

    s/far/a bit/

    > Major developers such as David and Al don't have trees that see wide
    > testing, their code only sees wide testing once it hits mainline. See
    > this message from David,

    Yes, networking has been an exception. I think this has been acceptable
    thus far because historically networking has tended to work better than
    other parts of the kernel. Although the fib_hash stuff was a bit of a

    > In particular, I think David's point about -mm being perceived as overly
    > experimental is fair.

    I agree - -mm breaks too often. You wouldn't believe the crap people throw
    at me :(. But a lot of problems get fixed this way too.

    > Recent experience seems to directly counter the assertion that only
    > well-tested code is landing in mainline, and it's not hard to pick
    > through the -rc changelogs to find non-trivial, non-bugfix modifications
    > to existing code.

    Once we hit -rc2 we shouldn't be doing that.

    > My own experience with netdev-2.6 bears this out as
    > well: I have several personal examples of bugs sitting in netdev (and
    > thus -mm) for quite a while, only being noticed when the code hits mainline.

    yes, I've had a couple of those. Not too many, fortunately. But having
    bugs leak in mainline is OK - we expect that. As long as it wasn't late in
    the cycle. If it was late in the cycle then, well,

    > Linus's assertion that "calling it -rc means developers should calm
    > down" (implying we should start concentrating on bug fixing rather than
    > more-fun stuff) is equally fanciful.
    > Why is it so hard to say "only bugfixes"?

    (It's not "only bugfixes". It's "only bugfixes, completely new stuff and
    documentation/comment fixes).

    But yes. When you see this please name names and thwap people.

    > The _reality_ is that there is _no_ point in time where you and Linus
    > allow for stabilization of the main tree prior to relesae. The release
    > criteria has devolved to a point where we call it done when the stack of
    > pancakes gets too high.

    That's simply wrong.

    For instance, 2.6.8-rc1-mm1-series had 252 patches. I'm now sitting on 726
    patches. That's 500 patches which are either non-bugfixes or minor
    bugfixes which are held back. The various bk tree maintainers do the same

    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 14:06    [W:0.033 / U:6.312 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site