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

[Beth Kirschner]

Ok -- I've updated the wiki page to state:
   "Small enhancements and tasks ... may be applied to only the most current maintenance release branch if they meet the following criteria:"

I'll float this proposal to the dev & user lists.

- Beth

On Jan 3, 2011, at 2:29 PM, Anthony Whyte wrote:

> There is much that I find attractive in this proposal.  However, implicit in the proposal as drafted is the disincentive it creates for those considering upgrading to new versions of the CLE.  This renders the proposal problematic for me; while schools are at liberty to run any version of the Sakai CLE there are a number of compelling reasons why a school should endeavor to stay close to the latest development work.  Security improvements are one reason but so too is the need we have as a Community of developers and users to have the latest versions of our code exercised by a solid cohort of Sakai adopters.  Moreover, encouraging schools to remain on older branches because we might sprinkle them occasionally with new stuff while at the same time neglecting to merge fixes into these branches in a timely manner is not, under current conditions, in the Community interest (have a look in Jira at the current backlog of 2.6.x and 2.7.x closed/resolved issues that need merging).
> 
> If the proposal's scope was tightened so that it 1) applies only to the current release branch and 2) takes effect only after 2.8.0 is released it would do much to eliminate the disincentive to upgrading that I find implicit in it.  In other words, small enhancements of the type described in the proposal could be applied to 2.8.x after 2.8.0 is released (and appear in the 2.8.1, 2.8.2 and so on) up until 2.9.0 is released, when 2.9.x becomes the (sole) target maintenance branch for future small enhancements.  Neither 2.7.x nor 2.6.x would be eligible for inclusion unless--and I think it worth discussing--we reconsider our Community "two branch" support strategy (which in reality is a three branch support strategy for much of the year, e.g., 2.6.x, 2.7.x and 2.8.x) or find a way to engage the Community more heavily in branch and release management work.
> 
> Cheers,
> 
> Anthony
> 
> 
> On Jan 3, 2011, at 11:04 AM, Berg, Alan wrote:
> 
>> OK, my 5 cents worth. The lack of available man power for quickly testing is a significant generic concern. However, out of cycle testing is the way forward to distribute load on QA.
>> We should add a fourth tick box to a Jira asking for central QA testing, so that a filter can be applied and worked through out of cycle.
>> 
>> The sooner a patch is tested the cheaper the cost of repair. Waiting around for a specific point in the major tag cycle increases the risk of losing the knowledge in an organization during the wait period. I therefore think the balance of argument is in favor of shorter change cycles.  I would like to see a more aggressively shorted cycle approach for indie projects and hope resource issues diminish as good stuff gets in quicker. I see Beth's proposal as a positive step forward in that direction.
>> 
>>> Perhaps an alternative is to turn over the maint branch to its
>> constituent users earlier than the release at which it becomes
>> "unsupported." This would certainly give more the interested
>> institutions and groups more freedom to do what they want.
>> 
>> New stuff get done in older versions with the risk of inconsistent patching of known issues.
>> 
>> 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 Seth Theriault [slt at columbia.edu]
>> Sent: 03 January 2011 16:45
>> To: Beth Kirschner
>> Cc: sakai2-tcc at collab.sakaiproject.org Committee
>> Subject: Re: [sakai2-tcc] [maint] Maintenance Branches: Enhancement vs Bug Merges
>> 
>> On 1/3/11 10:09 AM, Beth Kirschner wrote:
>>> 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?
>> 
>> I am still interested in what QA and RelMgmt have to say about
>> their ability to support the execution of this proposal. Even
>> though the "institution" doing the merging may be involved in the
>> testing, etc., there is no way that we can rely on it alone.
>> 
>> Perhaps an alternative is to turn over the maint branch to its
>> constituent users earlier than the release at which it becomes
>> "unsupported." This would certainly give more the interested
>> institutions and groups more freedom to do what they want.
>> 
>> Seth
>> _______________________________________________
>> 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
>> 
>> 
>