[sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges

[John Bush]

I agree with these suggestions, the requirements are exactly how we
operate internally with our distribution.

On Thu, Dec 2, 2010 at 7:02 AM, Berg, Alan <A.M.Berg at uva.nl> wrote:
> Sorry, try that again
>
> I also think a risk to Sakai 2.x is that it does not change functionally fast enough. I would therefore consider Beth's and David's suggestions a step in the right direction. Further, please signal to central QA changes worth testing.
>
> 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: Berg, Alan
> Sent: 02 December 2010 15:01
> To: David Horwitz; sakai2-tcc at collab.sakaiproject.org
> Subject: RE: [sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges
>
> 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 David Horwitz [david.horwitz at uct.ac.za]
> Sent: 02 December 2010 14:50
> To: sakai2-tcc at collab.sakaiproject.org
> Subject: Re: [sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges
>
> I would add:
>
> 1) If behaviour changes it should be configurable and set to off
> (current behaviour) in the branch
>
> D
>
> On 12/02/2010 03:32 PM, Beth Kirschner wrote:
>> The line between a "bug" and and "enhancement" is sometimes blurry (especially if we broaden the definition of "bug" to include usability problems). Additionally there are often small enhancements, low in risk and high in impact that have to wait a full year for release to the community code base because of our policy of only merging bug-fixes into maintenance branches. Some institutions can mitigate these long waits by maintaining their own release branches (msub) and pulling in enhancements early. Not everyone has the resources to to this.
>>
>> I'd like to propose that we rationalize the process for merging small tasks & enhancements into a maintenance branch as follows:
>>
>> Small enhancements and tasks may be merged into a maintenance branch if the following conditions are met:
>> 1) The change is narrow in scope (modest changes to a single project)
>> 2) The change does not require database changes
>> 3) The change is running in production at some institution
>>
>> An example of a good candidate for this type of task is http://jira.sakaiproject.org/browse/SAK-11003, which is running in production at multiple institutions (merged to their institutions's msub branches), but which will not be available to the broader Sakai community until 2.8 is released.
>>
>> This conversation feels familiar to me and it seems we may have discussed and agreed to this in the past, but wanted to bring up the topic with this group for a discussion and vote.
>>
>> Thoughts?
>> - Beth
>>
>> _______________________________________________
>> 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
>



-- 
John Bush
602-490-0470