![]() | |||||||||||||
Messages in this thread |
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 | ||||||||||||
| Last update: 2008-05-01 07:13 [W:0.986 / U:0.230 seconds] ©2003-2008 Jasper Spaans | |||||||||||||