[Building Sakai] [cle-release-team] Release thoughts

Wed Oct 30 18:09:26 PDT 2013

Questions:
-------------------------
* Do we want the release to be primarily schedule based or primarily scope/feature based? 
* Is there any reason not to make the criteria between Beta and Release Candidate to resolve all critical and blocker bugs? 
* Who would manage the branch that contains work that is not “trunk ready” starting in November, when we start using trunk for 2.10? After 2.10 is released, how do we identify which issues of that branch work are candidates for a 2.10.1 (or 10.1 or 4.1 or ChocolatePudding.dashofvanilla) vs the work that would target a Sakai 11? Right now, we have a pretty clear process for tagging which items go in which releases by using the merge flags. Would something like that still work? Would we need to keep the branch going to represent Sakai 11 while trunk is used for maintenance? 

I’m basically fine with whatever approach y’all want to take. I just think we should be explicit about our priorities, and as realistic as we can be about impact to schedule. And wherever possible, we should define measurable criteria passing between phases and for the release. And we should explicitly have a Change Control process, which in 2.9.x clearly was managed by TCC (now PMC). If the PMC is not in this business anymore, we need to establish a clear process for dealing which suggested changes during the release. I use AntiSamy as an example of the Change Control process. Change happens. People propose stuff that we didn’t think of in the early phases, but maybe makes sense to get in, or a Gradebook API bug appears late in the process and we need to determine if the release should go out, and the bug fixed post release, or if the release should be delayed. These kinds of things are hard to predict, hence we need a way to manage change. 

Maybe we should rename the Alpha phase to something else, but essentially we are already in Alpha, through the efforts being made to define scope. We could instead call this the scope definition and development phase (but Alpha is so much shorter). I guess I’m arguing for some label or code name for the part of the process we are already in.

Cheers,
Neal

Neal Caidin
Sakai CLE Community Coordinator
neal.caidin at apereo.org
Skype: nealkdin
Twitter: ncaidin

On Oct 30, 2013, at 7:52 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

>> Assuming we did do Sakai 10, what will be the version number after that? We have discussed before that major minor maintenance versions limit us, eg 2.9.2, 2.9.3. Would the next version be 11 or 10.1 ?
>> 
> 
> I'm with Bryan Holladay on this question [1].  Sakai 10 maintenance releases get versioned 10.1, 10.2, 10.3 . . . .  The next trunk based release, at least as I see it, gets versioned 11.
>> Also should this be decided on via some sort of democratic process? The other proposal is Sakai 4. I think 2.10 can be buried.
>> 
> 
> I prefer that we simply utilize the lazy consensus approach rather than conducting a poll as the former aligns with our meritocratic approach to governance.  I was hoping some other adventurous soul on the release team would propose the version change suggested by Matt but seeing no one step forward I thought I'd float a trial balloon prior to Thursday's team meeting.  In my opinion, switching to 10 does not require a formal vote of the PMC, since any of its members are free to raise a material objection should the proposal be brought forward (i.e., we intend to reversion trunk code X on Y date barring a material objection raised prior to Y - Z hours).
> 
> As for the 4.0 proposal, we've implemented the important bit--indie eradication--tabling the version question for consideration at a later date [2].   It's now a later date and  I've moved on from 4.  I like 10.  
> 
> Besides, when respected folk like Adam Marshall of Oxford offer their "half-groats worth" opinion that Sakai 10 is ok with them, I believe we are operating on pretty safe ground with respect to a version change.
> 
> Enough on versioning, what's your view on my "stay on trunk" trial balloon?
> 
> Cheers,
> 
> Anth
> 
> [1] http://collab.sakaiproject.org/pipermail/sakai2-tcc/2013-June/003595.html 
> 
> [2] http://collab.sakaiproject.org/pipermail/sakai2-tcc/2013-June/003563.html
> 
> 
> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
> 
> 
> On Oct 30, 2013, at 6:29 PM, Steve Swinsburg wrote:
> 
>> Assuming we did do Sakai 10, what will be the version number after that? We have discussed before that major minor maintenance versions limit us, eg 2.9.2, 2.9.3. Would the next version be 11 or 10.1 ?
>> 
>> I don't think we want to get too ridiculous with the numbers, just because Chrome increase the number often, doesn't mean it's a good model. They have auto updates so you don't really know what version you are on unless you look, not so for Sakai.
>> 
>> Also should this be decided on via some sort of democratic process? The other proposal is Sakai 4. I think 2.10 can be buried.
>> 
>> Cheers
>> Steve
>> 
>> sent from mobile device
>> 
>> On 31/10/2013 3:52 AM, "Anthony Whyte" <arwhyte at umich.edu> wrote:
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> 
> 
> _______________________________________________
> 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/sakai-dev/attachments/20131030/505a1411/attachment.html 