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

Mon Jan 10 17:38:58 PST 2011

HI all,

I'm coming in late to this one since I've been off the air over the break.

Something I have been thinking about for a while is that project teams should manage their own maintenance branches. This does already happen to an extent but I'd like to see it expanded. That way, the RM/branch management team can step back from merging fixes in components that are actively supported and focus on bug fix merges for core components, or where the tool is being supported by the maintenance team. 

Then, if a user sees a fix in JIRA that is in 2.8 but not in the 2.7.x branch, they can request the project team get it into that branch - the responsibility doesn't fall onto the branch management team to get that backported, tested and committed. Resources would be freed up, to an extent, and the core fixes could be done.

In regards to institutions that are running the maintenance branch to take responsibility, I think this has the potential of getting the branch into a dangerous state, depending on how we organise commit access. I wouldn't feel comfortable running a branch in production where a new developer at XYZ University is allowed to backport fixes and commit them to the branch. It might not get tested enough and may introduce regressions in other areas, making my workload even greater when the branch is broken in some way. We would need some level of code review before they are allowed free-reign, maybe I am just paranoid.

That said, we (ANU) haven't been able to commit any resources to 2.6 merges for some time due to other high priority projects and limited resources. So it would be nice if other institutions are able to contribute here and not just expect the RM/branch management team to do all the fixing in the branch they use - we just need to have a level of discretion and security applied so that those that are unable to do any fixing themselves don't end up with broken code.

cheers,
Steve

On 06/01/2011, at 4:53 AM, Anthony Whyte wrote:

> 
>> This offers us a chance to bring the branches closer together.
>> 
>> 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.
> 
> A certain credulity is required to accept the argument that branches will be brought "closer together" by back porting 5-10 minor enhancements a year under current conditions where active branches suffer from large merge backlogs. 
> 
> 2.6.x merge backlog (n=80) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12326
> 2.7.x merge backlog (n=90) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12212
> * 2.8.x merge backlog (n=22) https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12536
> 
> * 2.8 merge backlog usually drops to zero every two weeks prior to the issuance of the next 2.8 QA tag.
> 
>> "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.
> 
> You misstate the argument.  The problem I see is that stitching in a few minor enhancements into a maintenance branch without also ensuring that the branch is well maintained exaggerates the narrowing of the "distance" between branches.  If you really want to bring the branches closer together then I can point you to a substantial number of Jira tickets where a general fix has been applied to 2.8.x but still needs merging to 2.7.x and 2.6.x.  Help is needed here.
> 
>> "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'd like to see this proposal embedded in a more general reform proposal regarding branch/release management.  Thinking aloud and no doubt over ambitiously, perhaps *.x branch management should be "devolved" with responsibility being assumed by those organizations running off the *.x branch or using a tagged version of it.  If you run 2.6, 2.6.x is your responsibility; if you run 2.7, 2.7.x is your responsibility, and so on with the exception that security fixes (and back porting of security fixes) remains the responsibility of the Security WG.  The TCC and Foundation could work to encourage schools with common interests to self-organize and self-delegate.  If organizations running 2.7 want to back port a 2.8.0 minor enhancement it's up to them; if 2.6 deployers want to do the same, then again, it's their decision and equally their responsibility.  It's the way it's supposed to work isn't it?  
> 
> Devolution has implications for 2x release practices as well--maintenance releases (e.g., 2.6.4, 2.7.2, 2.8.1) could be handled by interested organizations as well.  If 2.7 organizations want a 2.7.2 release, they organize themselves to produce it, interacting as necessary with existing teams like the kernel team, the Samigo team, the maintenance team and QA.  Again, the TCC along with the Foundation could help to organize and coordinate these efforts but the work required would be the responsibility of interested parties.  
> 
> Cheers,
> 
> Anth
>   
> 
> On Jan 5, 2011, at 9:46 AM, Noah Botimer wrote:
> 
>> 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
>> 
> 
> _______________________________________________
> 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/20110111/22367464/attachment-0001.html 