Re: 2.6.19 -mm merge plans

[Andrew Morton]

On Thu, 21 Sep 2006 02:36:55 -0400
Jeff Garzik <jeff@xxxxxxxxxx> wrote:

> Andrew Morton wrote:
> > If you think that shortening the release cycle will cause people to be more
> > disciplined in their changes, to spend less time going berzerk and to spend
> > more time working with our users and testers on known bugs then I'm all
> > ears.
> 
> Honestly, I do think it would be positive.  It would shorten the 
> feedback loop, and get more changes out to testers.
> 
> It would also decrease the pressure of the 60+ trees trying to get 
> everything in, because they know the next release is 3-4 months away. 
> It would be _much_ easier to say "break the generic device stuff in 
> 2.6.20 not 2.6.19, please" if we knew 2.6.20 wasn't going to be a 2007 
> release.
> 

Well, it might be worth trying.  But there's a practical problem: how do we
get there when there's so much work pending?  If we skip some people's
trees then they'll get sore, and it's not obvious that it'll help much, as
the various trees are fairly unrelated (ie: parallelisable).

I guess the most practical way is to incrementally shorten the cycles.


<rerererepeating self>

I do think that any process change we make should send the signal "slow
down, be more careful, test and review it more carefully".  Or at least,
"try to make sure it compiles".

A compulsory Reviewed-by: would wedge things up nicely ;)
-
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/