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

[John Bush]

I have one comment which won't make me vote no, but...

It seems like schools especially some of the bigger players are moving
towards major new versions of sakai much slower. We are seeing this
with our client base and across Sakai in general. I think this is one
of the reasons QA is having a hard time getting resources.  There are
other reasons too, like Sakai3 or whatever you call it now, Sakai2 is
just a more stable platform now and is functionally rich, etc, etc.

Would we be enabling this trend of not moving towards new releases by
such a policy? I appreciate the fact that every organization has their
own needs, schedule, etc.  but fundamentally the whole community is
better off when people are aligned more closely.

I'm not sure I believe this to be true, but just throwing it out there.

On Fri, Dec 3, 2010 at 8:28 AM, Beth Kirschner <bkirschn at umich.edu> wrote:
> How's this: http://confluence.sakaiproject.org//x/bBFJB
>
> Are we ready for a vote or are there more comments?
>
> - Beth
>
> On Dec 2, 2010, at 8:11 PM, May, Megan Marie wrote:
>
>> Can someone volunteer to pull together this proposal on a Confluence page in the TCC space?
>>
>> Megan
>>
>> -----Original Message-----
>> From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Steve Swinsburg
>> Sent: Thursday, December 02, 2010 6:34 PM
>> To: csev
>> Cc: sakai2-tcc at collab.sakaiproject.org Committee
>> Subject: Re: [sakai2-tcc] Maintenance Branches: Enhancement vs Bug Merges
>>
>> If there is stuff you want to see running in a production 2.6, send it our way (ANU). And within this TCC I'm sure there would also be other eager candidates to test on 2.7?
>>
>> cheers,
>> s
>>
>>
>>
>> On 03/12/2010, at 3:55 AM, csev wrote:
>>
>>> I like this notion in general - in particular the non-distruptive bit and the option to turn off.
>>>
>>> I think a big issue will be how many versions back do we push something and who will QA those previous release branches.
>>>
>>> I can see a great benefit to schools back a level or two to back-port something to the 2-6-x branch as it allows them to eliminate a local patch earlier in their process and makes moving to new versions easier.
>>>
>>> However - I think that we need to have a school eager and ready to test and run something we are back porting.  So if some school is on 2.6 and there is a new feature that meets the criteria and wants it pulled back into 2-6-x - that school or those schools that want to run the patch should be willing to help in the testing of the 2-6-x branch after the code has been back ported.
>>>
>>> I think that unless there is a strong advocate and resources to support for a back port of a feature we should leave the older branches alone - we need to be mindful that community resources for QA/release are not unlimited.
>>>
>>> /Chuck
>>>
>>> On Dec 2, 2010, at 8:50 AM, David Horwitz wrote:
>>>
>>>> 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
>>
>> _______________________________________________
>> 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