[sakai2-tcc] Merging Changes into Maintenance Branches

[Beth Kirschner]

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.