Re: Default cache_hot_time value back to 10ms

From: Nick Piggin
Date: Wed Oct 06 2004 - 00:48:54 EST


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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/