[sakai2-tcc] Merging Changes into Maintenance Branches

[Beth Kirschner]

Hi Anthony,

   I think the criteria for branch managers is good, but the criteria for merging bug fixes is still unstated -- what if a bug fix significantly changes behavior or requires a database change? I'm not suggesting the decision for whether these merge requirements be pushed on your shoulders or any other branch manager, but simply that the criteria for setting the "merge" flag on a bug fix should be clearly stated.

   What I was proposing, beyond explicitly stating the criteria for setting the "merge" flag, was further delegating the actual merging. The responsibility for the testing of these back-ported fixes in maintenance branches should perhaps be different than that for enhancements, though, to not create road-blocks for getting fixes into maintenance branches.

- Beth

On Jan 5, 2011, at 5:06 PM, Anthony Whyte wrote:

> Published criteria for branch managers is here:
> 
> https://confluence.sakaiproject.org/display/REL/Sakai+2.x+branch+management+cheat+sheet
> 
> Delegating branch management responsibilities to tool/team leads is an existing practice that had its start back in 2009 when it became clear that part-time branch managers could neither keep up with the merge backlog nor assess adequately (largely due of the size of the code base) if particular fixes, such as those for OSP, could be safely merged to a maintenance branch.
> 
> OSP and Samigo have been managing their own branches for some time; so too Indie projects such as the Kernel, Msgcntr, Profile2 and Sitestats.  Other projects (mostly managed by UMich) also manage their maintenance branches (e.g., assignments, announcements, rwiki).  Assuming fixes are tested and verified, the delegation of branch management authority to those closest to the affected code (i.e., the team) appears to work; I don't have the impression that it has led to an increase in regressions or sloppy branch management practices when compared to past practices.  This is not to say that mistakes have not occurred; in particular, SAK fixes that depend on a Kernel commit are tricky and require an eye for detail when reviewing Jira tickets.
> 
> This said, delegating branch management to project teams has not led to the elimination of hefty merge backlogs for 2.6.x and 2.7.x.
> 
> 2.6.x merge backlog (n=80) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12326
> 2.7.x merge backlog (n=90) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12212
> 2.8.x merge backlog (n=22) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12536
> 
> There are several reasons for this continued state of affairs:
> 
> 1.  Resource constraints:  the 2x development team is small and its tasks are many.  Managing maintenance branches actively takes time and energy aware from other pressing concerns like new development and bug fixing.
> 2.  Competing commitments.  Local priorities often trump branch management work, especially in cases where a project is overseen by a single institution.
> 3.  QA shortfalls.  Testing and verification of bug fixes are often delayed due to a lack of available QA resources.   This adds to the backlog. 
> 4.  Maintenance Team practices: the Maintenance Team does not involve itself in branch management of the many projects it oversees preferring instead to focus on bug fixing.
> 5.  Old-style Branch Managers are few: I focus on 2.8 and range across the entire code base (even over areas ostensibly managed by others) in order to ensure that QA has something to test when I generate a tag.  John Cook (IU) and Steve Swinsburg (ANU) are focusing on 2.6 when they have time.  There is no one focusing on 2.7 at present.
> 6.  No glamour:  managing a branch, while necessary in order to get fixes into the hands of deployers, is not what many people consider as exciting work.  Recruiting volunteers is a hard sell.
> 
> I'm not sure the criteria you outline below is sufficient or workable; a critical or "blocker" regression would go nowhere according to your criteria -- or are you suggesting that some odd body like me is supposed to review and then handle merges that fall outside your criteria?  If that is the case, I still have a problem with it; I'd rather have you merging OSP fixes than me, for instance.  :)
> 
> Cheers,
> 
> Anth
> 
> On Jan 5, 2011, at 9:48 AM, Beth Kirschner wrote:
> 
>> Currently almost all bug fixes that are candidates for merging into a maintenance branch fall into one very long queue for the branch manager to merge. As a quick JIRA query can verify, this queue is huge. It also seems that there isn't a clear criteria for merging bug fixes into maintenance branches that is written down (I might be wrong on this -- so feel free to point me at the confluence page that does document a bug fix merge policy). 
>> 
>> I wonder if we need to put together a clear and objective set of requirements for merging bug fixes into maintenance branches, and then delegating the merging of these bug fixes to the tool/team leads? Since there is often a fairly grey line between a "bug" and an "enhancement", I think the requirements should perhaps mirror the proposed requirements for enhancements? I've often heard complaints that bug fixes are merged into maintenance branches without verifying the merge doesn't cause any unexpected behavior (i.e. merged without testing). By delegating the merge process, perhaps we can decrease the backlog and increase the quality of our code?
>> 
>> Tentative proposal for merging bug fixes:
>> 
>> 	• The change is narrow in scope (modest changes to a single project)
>> 	• The change has been reviewed and approved by tool lead for the maintenance branch
>> 	• The change does not require database changes
>> 	• The changes have to be reviewed for influence on i18n. If they have influence on i18n, they should be tested in 2 languages (country variants of same language are the same language for this counting).
>> 	• The change is non-disruptive to the user experience ( I.e. changes that don't require user retraining and are unlikely to break existing customizations). Exceptions to this rule may be made if the change is configurable and is disabled by default.
>> 	• Prior to merging, the change must be tested with the target maintenance branch, by the requesting institution, using a documented test plan.
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> 
>