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