[WG: Sakai QA] Branch management strategies

[Stephen Marquard]

Sometimes the point of a maintenance branch is stability and predictability rather than quality, or to put it another way, every fix introduces a risk of regression, and there is an appropriate balance between risk and improvement.

So making the "fix to merge" interval as short as possible and involve as few people as possible to increase the number of fixes going into maintenance branches is not necessary a desireable goal.

Let's say every 10 merged fixes introduce 1 functional regression. If you're running a maintenance branch in production, do you want old bugs fixed at the expense of new bugs introduced? Sometimes, to quote Glenn from way back, you want to fix "as little as possible" rather than "as much as possible".

Cheers
Stephen
 
>>> Anthony Whyte <arwhyte at umich.edu> 8/22/2009 5:25 AM >>> 
In other words, imagine the portfolio team with the puck in the  
offensive zone with an opportunity to score.  Why force them to dish  
the puck off to a branch manager back on the blue line when Beth  
Kirschner is in position to top-shelf the goalie with a wrist shot  
from just above the circle?

I think she should take the shot.

Anth



On Aug 21, 2009, at 7:16 PM, Noah Botimer wrote:

> I see this as strikingly accurate and exceedingly valuable.  
> Monitoring makes more sense in most cases than gate keeping. The  
> kernel is most sensitive and already handled with some additional  
> guidelines and care. Cross-module dependencies are next and require  
> some level of cooperation, but I wouldn't say they beg for central  
> administration.
>
> For modules with no inward dependencies, I see limited value in  
> handing things off for the sake of handing them off. The folks who  
> apply fixes are usually the closest to the knowledge of how things  
> should work out. They are also the ones who are ultimately  
> responsible for the well-being of that module. The ability to merge  
> closer to the time of fix, by more familiar hands, is valuable for a  
> raft of sanity and quality reasons. It's also worth noting that none  
> of this requires that we lose any visibility of, or ability to raise  
> issue with, changes going into maintenance branches.
>
> If I were cheeky on a Friday evening, I might say that oversee is  
> the right verb, not overdo.
>
> Thanks,
> -Noah


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Part.002
Type: application/octet-stream
Size: 272 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090822/c1bb682b/attachment.obj