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

[Jean-Francois Leveque]

I'd rather have it expressed directly.

May, Megan Marie a écrit :
> I believe that is implied 
> 
> -----Original Message-----
> From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Jean-Francois Leveque
> Sent: Thursday, January 27, 2011 11:46 AM
> To: Anthony Whyte
> Cc: sakai2-tcc at collab.sakaiproject.org Committee
> Subject: Re: [sakai2-tcc] Proposal: Merging Small Enhancements into Maintenance Branches
> 
> The proposal doesn't mention trunk. Shouldn't the enhancement already be in trunk and have been tested with trunk before doing anything on the maintenance branch?
> 
> Anthony Whyte a écrit :
>>>> If I was one, I wouldn't like "developers possessing project commit rights" to commit changes without my consent. 
>>
>> Project/team leads are not dictators nor has anyone to my knowledge empowered them on the CLE-side of the house with Apache, PMC-style powers with respect to project control.  Indeed, committers who have write access to a particular project (or even across the code base) do not need the permission or consent of others to commit a change.
>>
>> In short, we deliberately empower people via the committer mechanism (itself based on the meritocratic principle) to decide for themselves how they would like to contribute to the evolution of the CLE trunk.  Whether or not such decisions, expressed daily as individual commits, "stick" and find their way into a future release or into a maintenance branch depends on a wider community decision process involving fellow committers, QA testers, branch and release managers, and, in some cases, such as the introduction of new capabilities, the TCC.  
>>
>> The daily commit traffic recorded in source at sakaiproject.org is an expression of this empowerment.  In most cases it records a stream of sensible decisions undertaken by people granted write access to different areas of the code base--all conducted without an explicit requirement that some "tool lead" be consulted first for their consent before issuing a commit.
>>
>> Anyone designated a tool lead should make it his or her business to monitor this transparent flow of information regarding the evolution of trunk.  If they see a change they dislike they should raise a red flag and if necessary, as is their right as a committer, revert the change.
> 
> If the current leads and members of the TCC agree with you and because I'm not a lead, I have no reason to complain about this. I was just trying to find a safer way.
> 
>>>>> Changes that could impact internationalization negatively must be tested in two languages that are not variants of the same country.    
>>
>>>> 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?
>> My interpretation of the phrase "(country variants of same language are the same language for this counting)" was that the i18n WG prefer that testing occur in at least two distinct languages.
> 
> This was "2 languages (country variants of same language are the same language for this counting)"
> 
> I would have written "Changes that could impact internationalization negatively must be tested with two locales that are not country variants of same language". Do you agree with this change ?
> 
> J-F
> 
>> /Anth