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

[Paolo Ciarrocchi]

On Tue, 5 Oct 2004 23:39:58 -0700, Andrew Morton <akpm@xxxxxxxx> 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/

True, just a bit. But the the -pre/-rc thing is pretty confusing.
 
> > 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.
> 
> > 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.

Again, true.
But it's hard to understand why we have 'exceptions' to the dev model.
I still thing that the dev model should be  make official and all the
develpoers should follow such a rules.

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

I really think that:
- linus should start making -pre releases and then one (or a couple,
if needed) -rc candidate
- all the patches should go in -mm before landing in -pre
- maybe, try to match a few quality "goals'" ?



-- 
Paolo
Personal home page: www.ciarrocchi.tk
See my photos: http://paolociarrocchi.fotopic.net/
Buy cool stuff here: http://www.cafepress.com/paoloc
-
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/