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

[Noah Botimer]

I don't disagree, but I would list it as an assumption (not a bold font requirement) and use language like "if applicable".

There is a likely scenario where a widely beneficial enhancement is developed at an institution against their maintenance branch while the surrounding functionality moves on substantially in trunk, such that it is not relevant.

A case in point may be something with FCKeditor. Imagine that it went away for 2.9 but there were still good changes to apply in 2.8. For example, a better mechanism for handling uploads or a new file manager. There are certainly other possibilities in any tool that is moving substantially (maybe Profile 2?).

I think the thing to remember is that we are "governing" the behavior of about 20 people right now, all of whom we speak with regularly. Air-tight "legislation" to protect the masses from us, themselves, and any minute degree of subjectivity is just not a worthwhile investment of our time, especially since we are likely to need adjustments over time.

Thanks,
-Noah

On Jan 27, 2011, at 12:16 PM, Jean-Francois Leveque wrote:

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