[cle-release-team] [sakai2-tcc] CLE 2.9.4 vs CLE 2.10 effort

[Noah Botimer]

Yes. I made a note for myself to respond today -- "aren't these the same thing?" So, I'm glad people have mentioned that.

The point about fixes after big restructuring is well taken but, in general, any work on 2.9.x should happen in trunk first and be merged. I think it's a red herring to focus on whether developers focus on one or the other. It's really more about coordination and QA energy. If there is something truly wicked brewing, perhaps it should be in a branch and kept close to trunk for now and QA'd a bit before merge to trunk. (P.S., Git makes this a lot easier -- as evidenced by KNL-515.)

My feeling is that things should be getting QA when they get merged to 2.9.x, ASAP, regardless of the timing of releases.

If there is a fix that someone (developer, implementor, QA) thinks is pressing for 2.9.x, merge it and QA it. Waiting for release ramp-down is deficit spending and burns every time. Test data points spread out over time are easier to integrate than a huge lump of pass/fails in "release candidate" for something that is supposed to be stable.

Thanks,
-Noah

On Aug 29, 2013, at 11:50 PM, Charles Severance wrote:

> 
> On Aug 29, 2013, at 11:29 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 
>> Hi all,
>> 
>> If we focus on 2.10 and don't have resources for a full 2.9.4 release at this time then we should continue to merge to 2.9.x where appropriate - at some point in the future we could cut a 2.9.4 release. This goes directly to the goal that the branch is in a constantly releasable state.
> 
> This fits my thinking.  In effect we will almost certainly end up with a 2.9.4 one way or another - the question is it really just critical bug fixes that get merged or do we push non-trivial functionality into 2.9.4 like we have in 2.9.3 and 2.9.2.
> 
> In particular if agree that the primary focus will be TimHorton (I decided to take names from famous donut shops) it does mean that moving bug fixes back might be a little trickier and trickier over time.   
> 
> For example once we decide that TimHorton is the focus - I will go in and drop all the 2.8 templates and skins i portal in trunk.  I might do a touch of code refactoring between SkinnableCharonPortal and PortalService - particularly those comments where we say "this code is duplicated in two other places..." - and I might just drop LTI 2.0 into trunk of TimHorton with an experimental option to hide it instead of living in a Branch.
> 
> All these things mean it gets harder and harder to push large amounts of code changes back to the 2-9-x branch since stuff gets pushed around and things are not even in the same places.
> 
> It wont' be impossible to get a fix into 2-1-x just a little tricker potentially.
> 
> I am for having a small fix-only 2.9.4 sometime in the future with a few months of making real progress on the trunk toward the TimHorton release.  For example, I would love to see someone drop in a non-db event bus and enable it buy default :)   Lets make some real progress.
> 
> /Chuck
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130830/75a7d25c/attachment.html