Messages in this thread | | | Date | Thu, 1 May 2008 07:09:52 +0200 | From | Willy Tarreau <> | Subject | Re: Slow DOWN, please!!! |
| |
On Wed, Apr 30, 2008 at 08:15:00PM -0400, Chris Shoemaker wrote: > 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?
bug fixes are of course always possible, just that we limit important changes, i.e. the ones which randomly break and that take a lot of time to track down because everyone has changed something.
> -chris
willy
| |