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

[Jean-Francois Leveque]

Jean-Francois Leveque a écrit :
> Anthony Whyte a écrit :
>> The ". . . and no objections were raised . . ." clause in the process section translates into a proposal that requires TCC unanimous consent in order to back port useful, yet small enhancements.  Do we really need to be this controlling (or is it timid)?  Let the TCC exercise soft rather than hard power here as there exist sufficient senior CLE developers et al who can push back on small enhancement proposals that are considered problematic or dangerous.
>>
>> Second, I recommend removing all references to bug handling in the process and qualifications sections.  It muddies the waters of an otherwise promising initiative as well as treats as uncomplicated what is in fact a tricky game.  Moreover, too much discretion is accorded tool/project leads, a role that in many cases has lost all meaning across large swathes of the code base.  There is no mention of security vulnerability handling, an admittedly special case but one in which tool/project lead discretion carries little weight.  I could go on regarding the complicated nature of bug handling in a resource challenged environment but 'nuff said on that score.  The small enhancements proposal can be accommodated within our existing practices and can be amended later if a more detailed bug-handling proposal is drafted.
> 
> There are still project/tools leads that have meaning, AFAICT. If I was 
> one, I wouldn't like "developers possessing project commit rights" to 
> commit changes without my consent. What does "developers possessing 
> project commit rights" mean? AFAICT, a significant number of developers, 
> such as myself, have actual commit rights across projects.
> 
> For project/tools that have MT as lead, I think we should ask for one or 
> more voluntary members of the MT to act as lead in this case.
> 
> The proposal doesn't even mention trunk. Shouldn't the enhancements 
> already be in trunk and have been tested before doing anything on the 
> maintenance branch?
> 
>> I thought too we were going to lift the ban on back porting small enhancements to branches other than the most current?  I originally suggested this restriction but prefer now that it be dropped since I view the prospect of applying small enhancements to maintenance branches and maintenance releases as a way to satisfy the demand for incremental improvements while we spend the time required in trunk to solve some of the larger issues that we continue to push out because of the traditional time constraints we impose on ourselves (sometimes for no good reason).  If there is a good reason to push an enhancement to 2.7.x, why prevent it?
>>
>> I'd keep the proposal focused on the following:
>>
>> (I've added some revisions)
>>
>> 	•	[REVISED] Small enhancements may be applied to active maintenance release branches if they meet the following criteria:
>> 	◦	[REVISED] The change is narrow in scope [I DROPPED the parenthetical single project restriction; every now and again we might need to tweek the kernel to support an enhancement in another project]
>> 	◦	[REVISED] The change has been reviewed and approved by developers possessing project commit rights
>> 	◦	The change does not require database changes  [***not changing, although I consider this overly restrictive; we should evaluate on a case-by-case basis***]
>> 	◦	The change has been running in production for one month minimum
>> 	◦	[DELETE; INCORPORATE IN NEXT BULLET POINT] The changes have to be reviewed for impact on i18n. If they have impact on i18n, they should be tested in 2 languages (country variants of same language are the same language for this counting).
>> 	◦	[REVISED] The change is non-disruptive to the user experience (i.e. changes that do not require user retraining and are unlikely to break existing customizations).  The non-disruptive rule also covers i18n/L10n and accessibility concerns.  Changes that could impact internationalization negatively must be tested in two languages that are not variants of the same country.    Exceptions to this rule may be made if the change is configurable and is disabled by default.
> 
> Did you really mean testing i18n changes with en_US and en_GB was better 
> than with en_ZA and zu_ZA or have my English skills reached their limits?
> 
> J-F

Sorry, this was a later rewriting by Beth that I have a hard time to 
understand or agree with.

J-F

>> 	◦	Prior to merging, the change must be tested with the target maintenance branch, by the requesting institution, using a documented test plan.
>> 	◦	The change must be preceded by a public announcement on the production and dev lists that alert community members to the impending addition of a new feature in one or more maintenance branches. The announcement will describe the new feature, configuration options, test plans, relevant tickets, etc. When the change is committed a follow-up announcement listing the branch revision incorporating the change will be published. The information provided in such announcements will also be added to relevant release notes in Confluence and elsewhere.
>>
>>
>>
>> /Anth
>>
>>
>>
>>
>>
>>
>>
>> On Jan 26, 2011, at 12:37 PM, Beth Kirschner wrote:
>>
>>> Hello fellow TCC'ers,
>>>
>>>   I think it's time to put this to a vote. The proposal is available in confluence at:
>>> 	https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy+%28tentative%29
>>>
>>>   Please try to re-read the proposal as it stands today and vote within the next week (February 2nd).
>>>
>>> Thanks,
>>> - Beth
>>>
>>> On Jan 25, 2011, at 12:35 PM, Noah Botimer wrote:
>>>
>>>> For what it's worth...
>>>>
>>>> I'm still in support of this proposal and would like to see us decide whether the discussion is going forward or not.
>>>>
>>>> As far as my opinion of the substance, I think moving the TCC into a "these people should know about it" role is right. I'm not interested in painting a picture of (or participating in) an overly bureaucratic process that would discourage the suggestions of enhancement. The objective criteria are pretty clear and appropriate, and I think the communications items outline good practice for community awareness.
>>>>
>>>> I also think that we are only likely to see requests from engaged community members. We should recognize that every item that goes in under known constraints documents the platform better and relieves load on institutions that would have to expend effort tracking and applying patches. These conscientious merges would improve our product and reduce overall waste in the ecosystem.
>>>>
>>>> Thanks,
>>>> -Noah
>>>>
>>>>
>>>> P.S. I changed "influence" to "impact" in the bullet point about internationalization (in blue).
>>>>
>>>> On Jan 20, 2011, at 4:16 PM, Beth Kirschner wrote:
>>>>
>>>>> I've tried to translate the TCC discussion into an objective set of guidelines, but seem to have generally failed to find the right wording :-(
>>>>> If anyone would like to update the proposal to reflect your understanding of what was said, feel free.
>>>>>
>>>>> I've just made a few more changes (highlighted in green), that hopefully better address the process that was discussed. I wasn't trying to write up the minutes of the discussion, just the outcome. I changed the word "vote" to "oversight", but not being quite sure what that means, I also added this sentence: "This means that the merge candidate was discussed, and no objections were raised (though no formal vote is required)." 
>>>>>
>>>>> It's my hope that the guidelines in place would set the bar fairly high for anyone to even consider requesting a merge. The benefits, I hope, would be providing low-risk enhancements that could significantly improve the user experience for large groups of users in the near term.
>>>>>
>>>>> - Beth
>>>>>
>>>>> On Jan 20, 2011, at 1:24 PM, May, Megan Marie wrote:
>>>>>
>>>>>> Hi, 
>>>>>>  This addition is a result of some discussion we had on the conference call last week.  Here's my take on that -    There seems to be a lot of hesitation about moving forward with this proposal.   Some of the reasons included
>>>>>> - Resource concerns
>>>>>> - Expectations of project leads being unclear
>>>>>> - User impact of changes
>>>>>> - Communication 
>>>>>> - Major shift in community practices 
>>>>>>
>>>>>> Given these concerns, it was suggested that this process be tried out (ie we'd be voting on *trying* this process out for X number of months) and as a part of that the TC would provide oversight on the enhancements going in.  (FWIW, I explicitly requested this).     Once this has proven successful and expectations of tool leads are better know, we'd move to leaving the decision up to the leads.  
>>>>>>
>>>>>> As Seth mentioned, the proposal definitely doesn't reflect my understanding of that discussion, 
>>>>>> Megan 
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Seth Theriault
>>>>>> Sent: Wednesday, January 19, 2011 9:05 PM
>>>>>> To: sakai2-tcc at collab.sakaiproject.org
>>>>>> Subject: Re: [sakai2-tcc] Proposal: Merging Small Enhancements into Maintenance Branches
>>>>>>
>>>>>> Beth Kirschner wrote:
>>>>>>
>>>>>>> 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+Mer
>>>>>>> ge+Policy+%28tentative%29
>>>>>> I don't particularly care for an explicit TCC vote on each enhancement because I think it unnecessarily adds to the overhead. If the proposer and the tool lead(s) are in agreement about the enhancement, I see no need for TCC intervention. In case of disagreement, I feel that the TCC could function as some sort of appeals venue. None of this precludes proposers from bring their enhancement to the attention of the TCC for advice or review.
>>>>>>
>>>>>> In addition, on the call and elsewhere, there has been discussion of an explicit trial period for this proposal. I see no mention of that anywhere in this proposal. Something like this needs a review by the TCC after a while, e.g. 6 months.
>>>>>>
>>>>>> Seth