[WG: Sakai QA] Branch management strategies

Anthony Whyte arwhyte at umich.edu
Sun Aug 23 09:05:33 PDT 2009


With some 945 open and unresolved issues already logged against some  
flavor of 2.6 a cynic might draw the conclusion that we are fixing "as  
little as possible."  But what interests me at the moment are the 99  
closed issues that Jira tells me are ready for merging to 2.6.x.*  If  
each closed issue represents a verified and tested fix (and an  
expenditure of time, effort and money) then working them into 2.6.x in  
a judicious (i.e., by priority) yet expeditious manner makes sense to  
me, especially given that future maintenance releases originate from  
*.x maintenance branches.

Moreover, if some project teams, especially those considering adopting  
separate release schedules for their projects--which by definition  
means taking over their own branch management--can assist with *.x  
branch management by handling their own merging, then we will reduce  
the time it takes for a fix to make its way into production.  Some  
will not want to do so and for them a branch manager can assist;  
others will embrace the opportunity.  Branch managers with a bit more  
branch-management time on their hands could assist in tracking the  
flow of fixes moving towards and into the *.x branch (as well as  
noting regressions), reporting activities that would help promote  
branch predictability.

Introducing regressions is never good; letting verified and tested  
fixes hang around in trunk longer than necessary is also not good.  As  
another Sakai community member whom I respect wrote recently regarding  
the interminable release delays that plagued 2.6.0: "[s]ometimes we  
stretch the 'release early release often' dictum to the breaking point."

Cheers,

Anth


* Issue type: 62 bugs, 9 tasks, 28 sub-tasks.  There are another 77  
resolved issues that have the 2.6.x field set to merge.  It is  
important to note that in cases were field information is not up-to- 
date Jira can lie.  It's quite possible that some of these issues have  
already been merged into 2.6.x.


On Aug 22, 2009, at 3:08 AM, Stephen Marquard wrote:

> 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
>
>
> <Part.002>_______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090823/3e83b2e4/attachment.bin 


More information about the sakai-qa mailing list