[sakai2-tcc] Proposal: Merging Small Enhancements into Maintenance Branches

[Beth Kirschner]

On Jan 18, 2011, at 9:38 AM, Jean-Francois Leveque wrote:

> Beth:
> 
> I think the bug fixes process description does not fit current practices. It does not account the fact that the MT does not work on branch management (https://confluence.sakaiproject.org/display/MNT/process), even if it could be considered lead as set in JIRA. It does not account the work done by the maintenance branch managers (I cannot find an up-to-date page with a list of 2.6.x and 2.7.x branch managers on confluence). It does not account the fact that sometimes the lead is not involved in maintenance branch work.
> 
I had posted a separate proposal to define/document what is the process for merging bug fixes, but it gained no traction. For now, I can either remove all reference to merging bugs, or revise the statement as follows (which I believe is true):
	• Bug fixes may be candidates to merge into a maintenance branch at the discretion of the project/tool lead

> The whole process description does not state who's gonna do the merges. The problem is, AFAICT, that we don't have enough maintenance branch manager time to deal with merging the bug fixes. The state of the merge requests status for 2.7.x issues could be used as proof.
> 
Agreed and a separate problem that needs to be addressed regardless of the state of this proposal.

> I think the community contribution in maintenance branch management is not up to the task of merging bug fixes and it would be a bad idea to try to do more merges before we have more contribution. Maybe this tentative policy could be evaluated again in 3, 6 months or at least when 2.8.0 has been released.
> 
> As far as the qualifications for enhancements are concerned, lots of questions are pending:
> Who evaluates the scope of the change?
> Who reviews the change if it's code under MT lead?
> Who review the influence on i18n?
> How making the change non-disruptive can keep the scope of the change small?
> Could the community members have a way to oppose the merge before it's done instead of having to deal with it when it's done? How long in advance will the change be announced?
> How are we avoiding merging changes that are only requested by one or a few institution and seen as dangerous by others?
> How are we dealing with the increased maintenance cost from code lead and QA point of view?
> 
The guidelines are an attempt to answer these questions, based on input from this list.

> I think we lack the people to populate all those who questions and this is another reason to delay the evaluation of this tentative policy.
> 
It's all about risk vs benefits. I understand your concerns.

- Beth

> J-F
> 
> Beth Kirschner a écrit :
>> Hi all,
>>   Following today's TCC phone call, we decided to update the following proposal by requiring a vote of any and all enhancements prior to merging them into a maintenance branch: https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy+%28tentative%29
>>   We decided to allow one additional week to re-read the current proposal and respond on this list before asking for a vote on January 20th.
>> Thanks,
>> - Beth
> 
>