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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).