Messages in this thread | | | Date | Wed, 06 Oct 2004 15:46:41 +1000 | From | Nick Piggin <> | Subject | Re: Default cache_hot_time value back to 10ms |
| |
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 > code into the kernel.org tree, well, that's a cost. That latency may be > high but the bandwidth is pretty good. > > There are exceptions of course. Completely new > drivers/filesystems/architectures can go in any old time becasue they won't > break existing setups. Although I do tend to hold back on even these in > the (probably overoptimistic) hope that people will then concentrate on > mainline bug fixing and testing. > > >> It would have caught the NFS bug that made 2.6.8.1, and probably >> the cd burning problems... Or is Linus' patching finger just too >> itchy? > > > uh, let's say that incident was "proof by counter example". >
Heh :)
OK I agree on all these points. And yeah it has worked quite well...
But by real -rc, I mean 2.6.9 is a week after 2.6.9-rcx minus the extraversion string; nothing more.
The main point (for me, at least) is that if -rc1 comes out, and I'm still working on some bug or having something else tested then I can hurry up and/or send you and Linus a polite email saying don't release yet.
Would probably be a help for people running automated testing and regression tests, etc. And just generally increase the userbase a little bit.
Catching the odd paper bag bug would be a fringe benefit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |