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

May, Megan Marie mmmay at indiana.edu
Mon Jan 3 08:12:37 PST 2011


Has this proposal been floated to the greater community for questions, comments, concerns?  

Megan 

-----Original Message-----
From: sakai2-tcc-bounces at collab.sakaiproject.org [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Beth Kirschner
Sent: Monday, January 03, 2011 10:09 AM
To: sakai2-tcc at collab.sakaiproject.org Committee
Subject: Re: [sakai2-tcc] [maint] Maintenance Branches: Enhancement vs Bug Merges

Happy New Year! The conversation on this thread died down weeks ago without a formal vote. The proposal is documented at:
	https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy+%28tentative%29

I'd like to call for a vote...

Thoughts?
- Beth

On Dec 8, 2010, at 4:21 PM, Noah Botimer wrote:

> To front-load my support, +1. If you can't tell me how to test it, I'm not convinced it's modest or fully understood -- thereby violating my concept of our promise of what maintenance releases mean.
> 
> 
> So, for more...
> 
> I don't think that it's too much to ask to have these exceptional cases (5-10 a year?) documented in a standard form, including a few words of how to verify them. Our JIRA tickets are just too numerous and inconsistent to use as a real feature list.
> 
> The goal isn't to be a barrier; it's to spend about 10-20 minutes up front to explain out-of-band features and save the puzzlement and frustration of mysterious changes. These might not be right for the job, but perhaps these templates could be inspiration for a lightweight tool:
> 
> http://confluence.sakaiproject.org/display/OSP/OSP+Feature+Template
> http://confluence.sakaiproject.org/display/OSP/OSP-SPEC+-+Specificatio
> n+Template
> 
> 
> A few completed examples (for admittedly more involved features than we might expect in maintenance):
> 
> http://confluence.sakaiproject.org/display/OSP/Evaluator+Selection+Red
> esign 
> http://confluence.sakaiproject.org/display/OSP/Duplicating+portfolios
> http://confluence.sakaiproject.org/display/OSP/Indiana+University+Matr
> ices+Enhancements 
> http://confluence.sakaiproject.org/display/OSP/Collaborative+Portfolio
> +Contributions
> 
> Thanks,
> -Noah
> 
> On Dec 8, 2010, at 2:58 PM, Beth Kirschner wrote:
> 
>> I believe the intent is that the institution doing the merge is responsible for testing. Perhaps we could require a Test Plan be documented and followed in the JIRA?
>> 
>> - Beth
>> 
>> On Dec 8, 2010, at 2:48 PM, Seth Theriault wrote:
>> 
>>> Beth Kirschner wrote:
>>> 
>>>> - The change must be QA tested with the maintenance branch before 
>>>> the merge
>>> 
>>> I'd like to hear whether QA and RelMgmt thinks they have the 
>>> capacity to support this condition given that we are currently 
>>> maintaining and/or testing up to a half-dozen "releases" at a time 
>>> (currently 2.6, 2.7, 2.8, plus their respective kernels) plus the 
>>> indies.
>>> 
>>> Seth
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

_______________________________________________
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