Re: new dev model (was Re: Default cache_hot_time value back to 10ms)
From: Jeff Garzik
Date: Wed Oct 06 2004 - 14:40:13 EST
Ingo Molnar wrote:
On Wed, 6 Oct 2004, Jeff Garzik wrote:
The _reality_ is that there is _no_ point in time where you and Linus
allow for stabilization of the main tree prior to relesae. [...]
i dont think this is fair to Andrew - there's hundreds of patches in his
tree that are scheduled for 2.6.10 not 2.6.9.
you are right that -mm is experimental, but the latency of bugfixes is the
lowest i've ever seen in any Linux tree, which is quite amazing
considering the hundreds of patches.
I said "stabilization of the main tree" for a reason :) Like a
"mini-Andrew", I have over 100 net driver csets waiting for 2.6.10 as well.
The crucial point is establishing a psychology where maintainers only
submit (and only apply) bug fixes in -rc series. As long as random
stuff (like fasync in 2.6.8 release) is getting applied at the last
minute, we are
* destroying the validity of testing done in -rc prior to release, and
* reducing the value of user testing
* discouraging users from treating -rc as anything but a 'devel' release
(as opposed to a 'stable' release)
it is also correct that the pile of patches in the -mm tree mask the QA
effects of testing done on -mm, so testing -BK separately is just as
important at this stage.
The simple fact is that -mm doesn't receive _nearly_ the amount of
testing that a 2.6.x -BK snapshot does, which in turn doesn't receive
_nearly_ the amount of testing that a 2.6.x-rc release gets.
The increase in the amount of testing, and amount of feedback I get for
my stuff in -mm/-bk versus -rc/release is a very large margin. For this
reason, one cannot hold up testing in -mm as nearly having the value of
testing in -rc.
But with the diminished signal/noise ratio of current -rc...
Jeff
-
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/