Re: new dev model (was Re: Default cache_hot_time value back to 10ms)

[Jeff Garzik <jgarzik@pobox.com>]

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