Re: Slow DOWN, please!!!

[Chris Shoemaker <c.shoemaker@cox.net>]

On Thu, May 01, 2008 at 01:12:21AM +0200, Willy Tarreau wrote:
> On Thu, May 01, 2008 at 12:39:01AM +0200, Rafael J. Wysocki wrote:
> > In fact, so many changes go in at a time during a merge window, that we often
> > can't really say which of them causes the breakage observed by testers and
> > bisection, that IMO should really be a last-resort tool, is used on the main
> > debugging techinque.
> 
> Maybe we could slightly improve the process by releasing more often, but
> based on topics. Small sets of minimally-overlapping topics would get
> merged in each release, and other topics would only be allowed to pull
> fixes. That way everybody still gets some work merged, everybody tests
> and problems are more easily spotted.
> 
> I know this is in part what Andrew tries to do when proposing to
> integrate trees, but maybe some approximate rules should be proposed
> in order for developers to organize their works. This would begin
> with announcing topics to be considered for next branch very early.
> This would also make it more natural for developers to have creation
> and bug-tracking phases.

What would this look like, notionally?  Say the releases were twice as
frequent with Stage A and Stage B.  How could the topic be grouped
into the stages?  Could bugfixes of any type be merged in either
window?  Would this only apply to "new" features, API changes, etc? or
would maintenance-type changes have to be assigned to a stage, too?

-chris