From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Jeff Garzik <jgarzik@pobox.com>,
nickpiggin@yahoo.com.au, kenneth.w.chen@intel.com,
mingo@redhat.com, linux-kernel@vger.kernel.org, judith@osdl.org
Subject: Re: new dev model (was Re: Default cache_hot_time value back to 10ms)
Date: Wed, 6 Oct 2004 10:56:18 +0200 [thread overview]
Message-ID: <4d8e3fd30410060156b615f55@mail.gmail.com> (raw)
In-Reply-To: <20041005233958.522972a9.akpm@osdl.org>
On Tue, 5 Oct 2004 23:39:58 -0700, Andrew Morton <akpm@osdl.org> wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > Andrew Morton wrote:
> > > Nick Piggin <nickpiggin@yahoo.com.au> 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
next prev parent reply other threads:[~2004-10-06 8:57 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 0:42 Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 0:47 ` Con Kolivas
2004-10-06 1:02 ` Nick Piggin
2004-10-06 0:58 ` Nick Piggin
2004-10-06 3:55 ` Andrew Morton
2004-10-06 4:30 ` Nick Piggin
2004-10-06 4:51 ` Andrew Morton
2004-10-06 5:00 ` Nick Piggin
2004-10-06 5:09 ` Andrew Morton
2004-10-06 5:21 ` Nick Piggin
2004-10-06 5:33 ` Andrew Morton
2004-10-06 5:46 ` Nick Piggin
2004-10-06 6:19 ` new dev model (was Re: Default cache_hot_time value back to 10ms) Jeff Garzik
2004-10-06 6:39 ` Andrew Morton
2004-10-06 8:56 ` Paolo Ciarrocchi [this message]
2004-10-06 9:44 ` bert hubert
2004-10-06 14:00 ` Andries Brouwer
2004-10-06 19:40 ` Jeff Garzik
2004-10-06 19:48 ` Jeff Garzik
2004-10-06 19:58 ` Jeff Garzik
2004-10-06 20:37 ` Geert Uytterhoeven
2004-10-07 1:08 ` Jeff Garzik
2004-10-07 0:02 ` Matt Mackall
2004-10-06 9:23 ` Ingo Molnar
2004-10-06 9:57 ` Paolo Ciarrocchi
2004-10-06 19:33 ` Jeff Garzik
2004-10-06 22:23 ` Martin J. Bligh
2004-10-06 5:52 ` Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 19:27 ` Chen, Kenneth W
2004-10-06 19:39 ` Andrew Morton
2004-10-06 20:38 ` Chen, Kenneth W
2004-10-06 20:43 ` Andrew Morton
2004-10-06 23:14 ` Chen, Kenneth W
2004-10-07 2:26 ` Nick Piggin
2004-10-07 6:29 ` Ingo Molnar
2004-10-07 7:08 ` Jeff Garzik
2004-10-07 7:26 ` Ingo Molnar
2004-10-06 20:50 ` Ingo Molnar
2004-10-06 21:03 ` Chen, Kenneth W
2004-10-06 7:48 ` Ingo Molnar
2004-10-06 17:18 ` Chen, Kenneth W
2004-10-06 19:55 ` Ingo Molnar
2004-10-06 22:46 ` Peter Williams
2004-10-06 13:29 ` [patch] sched: auto-tuning task-migration Ingo Molnar
2004-10-06 13:44 ` Nick Piggin
2004-10-06 17:49 ` Chen, Kenneth W
2004-10-06 20:04 ` Ingo Molnar
2004-10-06 21:18 ` Chen, Kenneth W
2004-10-07 6:10 ` Ingo Molnar
2005-02-21 5:08 ` Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d8e3fd30410060156b615f55@mail.gmail.com \
--to=paolo.ciarrocchi@gmail.com \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=judith@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.