[Building Sakai] Release thoughts

[Anthony Whyte]

I've not been able to make the last couple of team calls due to local commitments but I'd like to float some thoughts on the current strawman release proposal. [1]  Consider this a pre-proposal.

10

Earlier in the year I proposed we version the next trunk-based release Sakai 4.0.  Matt Jones countered with Sakai 10, a truly compelling suggestion that allows us to celebrate in two digits both the staying power of the community and the inaugural release of Sakai 1.0 in 2004.  Bryan Holladay provided yet further reasons why we should put Sakai 2.x versioning in our wake.  Since then, Sakai 10 has gained a certain traction on the lists.  I recommend that we adopt the Jones proposal before too much more ink gets spilled in Confluence and elsewhere regarding 2.10 and instead set our sights on releasing Sakai 10 in 2014.  

Don't branch for alpha and beta tags (stay on trunk)

By long tradition we branch months in advance of the release.  I believe it's time that we end this practice and instead focus our energies on getting trunk into a releasable state.  In other words, we don't branch in November just so we can generate alpha tags that we know are neither feature complete nor likely to be QA'd.  As we have discussed on the team calls the alpha/beta tag distinction is a fiction since no reliable measures exist to mark the moment when moving from one tag type to another is justified.  Besides, what really matters is the shift from beta to RC and we do have criteria in place to distinguish between the two types of tags.  Indeed, the best that we have come up with to distinguish between alpha and beta tags is that the former will not be feature complete, while the latter presumably will.  On reflection, this is not a helpful distinction as it propels us in the direction of branching trunk prematurely and leads us into discussions about whether or not committers should be free to merge their own stuff to the branch during the alpha stage. [2]  I agree that devs should be free to merge their fixes to the "alpha" 10 branch but why bother?  Why double up on the work (commit to trunk, then merge to a branch)?  Branching early equates to more work; unproductive work.

Instead I recommend that we keep the focus squarely on trunk, branching only when we are ready to issue the first RC tag.  I reckon that will be in April (as has been proposed).  Under this JIT branching approach "branch management" of trunk is everyone's responsibility and branch managers only need to be designated after we create a stable branch for the RC and the GA release.  

This approach should inconvenience no one.  If there is work taking place between November-April that is not "trunk ready" it should be held back in a branch until we cut the RC for 10.  

Constraints

We face two key constraints: 1) QA commitments--not hearing otherwise I assume at present that we lack firm commitments--and 2) contributor/committer availability.  Historically, QA tends to pick up in the new year following the holidays as the community begins to rally around the prospect of a new release and schools like Rutgers start working with the beta tags.  I don't see that rhythm changing for this cycle and is yet another reason why we should forgo branching prematurely.  Second, in certain cases, the availability of key committers actually increases over the holiday season (I'm thinking of Chuck Severance (csev) here among others) and we should both recognize that lag in availability and harness it productively before we make the decision to branch.  

Velocity

John Bush has argued (elsewhere) that now is not the time for us to be conservative and that we need to find ways to increase project velocity.  I agree with him.  Branching in Nove is oh so conservative and forces us to forgo opportunities between now and the early 2014 to enhance Sakai 10 before we release it.  LTI 2.0 is a case in point.   The spec is nearly ready but a Sakai implementation is not.  We want LTI 2.0 in 10.  Yet csev will be hard-pressed to make a mid-Nov freeze (he teaches after all).  We can issue alpha tags without and LTI upgrade but as I noted above, why bother?  Then there is the dashboard.  It's not yet ready for prime-time but we should move the code to core svn and make it a (stealthed) stretch goal for 10 or a subsequent 10.x point release.  We should at least get it in the chute instead of considering it Michigan's problem for yet another cycle.  We've got other potential capabilities that need to prepped for inclusion, evaluated and moved to core svn: roster2, signup, etc for 10 or a subsequent release.  I doubt we can get all that done prior to a mid-November freeze date.

I could go on but I think I've said enough.  Forget branching in November.  Trunk is 10. 

Cheers,

Anth


[1] http://collab.sakaiproject.org/pipermail/cle-release-team/2013-October/011186.html; https://confluence.sakaiproject.org/display/REL/Sakai+2.10+Release+Schedule
[2] http://collab.sakaiproject.org/pipermail/cle-release-team/2013-October/011220.html

anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131030/5e15a1a9/attachment.html