Re: new dev model (was Re: Default cache_hot_time value back to 10ms)

[Jeff Garzik]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@xxxxxxxxx> wrote:
>
> > Andrew Morton wrote:
> >
> > > Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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, 
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=109648930728731&w=2
>
>
> 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
> fiasco.

That's a prime example, yes...


> > 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.

Why does -rc2 have to be a magic number?  Does that really make sense to 
users that we want to be testing our stuff?

"We picked a magic number, after which, we hope it becomes more stable 
even if it doesn't work out like that in practice"


> > 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,
> bad-call-won't-do-that-again.
>
>
> > 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.

I thought I just did ;-)


> > 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
> thing.

Sure I'm sitting on over 100 net driver csets myself.  I'm glad, but the 
overall point is still that "-rc" -- which stands for Release Candidate 
-- is nowhere near release candidate status when -rc1 hits, and fluff 
like sparse notations and changes like the fasync API change in 2.6.8 
always seem to sneak in at the last minute, further belieing(sp?) the 
supposed Release Candidate status.

No matter the effort of maintainers to hold back patches, every 
violation of the Release Candidate Bugfixes Only policy serves to 
undermine user confidence and invalidate previous Q/A work.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/