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

David Horwitz david.horwitz at uct.ac.za
Thu Jan 27 23:16:58 PST 2011


+1



On 01/28/2011 09:05 AM, Berg, Alan wrote:
> Thank you Beth for your patience.
> +1
>
> Alan
>
> Alan Berg
> QA Director - The Sakai Foundation
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
> http://home.uva.nl/a.m.berg
>
> ________________________________________
> From: sakai2-tcc-bounces at collab.sakaiproject.org [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Beth Kirschner [bkirschn at umich.edu]
> Sent: 27 January 2011 18:26
> To: sakai2-tcc at collab.sakaiproject.org Committee
> Subject: Re: [sakai2-tcc] Proposal: Merging Small Enhancements  into    Maintenance Branches
>
> I'd really like to move past the discussion phase -- this email thread has been active since late last year. In the US Senate, there's a procedure known as a "filibuster" that prevents the Senate from voting on a proposed law if a minority of senators wish to continue discussion. This filibuster procedure is effectively used to prevent many laws from being voted on and enacted. I hope we're not going there. There's been plenty of time to tweak the proposal.
>
> Specific to the two recent concerns, I've reverted the "developers possessing project commit rights" phrase back to the original text, in the spirit of locking down the proposal as is. It's been standard practice for years (and is probably documented somewhere), that all commits must first go to trunk.
>
> I vote +1 on the proposal as it stands today.
>
> - Beth
>
> 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
>>     
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>   


More information about the sakai2-tcc mailing list