[sakai2-tcc] Merging Changes into Maintenance Branches

Thu Jan 6 10:17:59 PST 2011

Lots of important concerns have been raised.  Here is a radical suggestion: switch to an (almost) open commit then review approach to the maintenance branches.  This would work by having a low barrier for someone getting on the commit list for any maintenance branches that are not already actively managed.  All commits would be subject to review / reversion by any committer.  Any commit would be subject to the criteria below (and to other valid technical concerns).  The intent would be to make it easy for someone to contribute safe changes while not opening up the code base to arbitrary changes or attitude wars.  Anyone could be removed from the commit list if the TCC agrees that they aren't contributing to improving the code base of the maintenance branch.

The level of evidence I have in mind being added to the commit list is submitting an acceptable patch to existing commiters.  Behavior that might get you kicked off a commit list is extensive reformatting of existing source files or trying to ignore the criteria agreed on for making a maintenance branch change.

Hopefully this would allow various people to add fixes appropriate to their production needs while not requiring anyone who wants to contribute a change to worry about having to take on all responsibility for a particular project.

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu

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
>> 
>> 
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110106/f9d3ea87/attachment.html 