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

Wed Jan 5 06:46:39 PST 2011

My impression is that there are a few factors to co-optimize:

  * The stability of the UI such that implementors aren't surprised with retraining and support issues by picking up releases.

  * The ability to address known functionality gaps without a full upgrade/conversion.

  * The transition/upgrade/conversion cost in terms of managing change complexity.

In short, I agree with Dave here. I have long been a supporter of a stable path on maintenance releases ("no surprises"), and I think the proposal addresses those concerns well enough. This offers us a chance to bring the branches closer together.

I think the argument that people are less likely to upgrade if the distance is less is mostly fallacious and that, rather, the closer they are, the easier the upgrades are. Holding back safe, desirable functionality that people are willing to backport in the hopes of keeping people on the leading edge robs them of the autonomy we generally advocate. It doesn't feel like a healthy impetus for upgrades.

Unless or until we have a model where there is some kind of more aggressive, "next version" release in the general public space or we have accelerated major releases, this flexibility is important to the balance of stability and innovation. I think the reality is that our collective experience makes us good judges of the kinds of proven items that could be backported to help maintain and increase the value of an institution's investment, while easing transitions to our upcoming offerings.

I'm in favor of a proposal and practice shift that helps to avoid leaving implementors in a lurch between their campus needs and a community stance based on shaky motivation.

Thanks,
-Noah

On Jan 4, 2011, at 4:57 PM, David Haines wrote:

> IMHO it would be a significant mistake to wait until 2.8 to implement this.  People will be running 2.7 for quite a while whether or not 2.8 comes out on time.  I suspect that not adding small safe capabilities to 2.7 is likely to create more frustration with 2.7 falling behind than incentive to move to 2.8.  I see nothing in this suggestion that mandates adding changes to 2.7 if 2.8 is out, but forbidding it leaves the majority of installations continuing to wait for bits of functionality that would be useful.
> 
> - Dave 
> 
> David Haines
> CTools Developer
> Digital Media Commons
> University of Michigan 
> dlhaines at umich.edu
> 
> 
> 
> 
> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110105/aafca4b8/attachment.html 