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

Tue Nov 12 11:05:30 PST 2013

Did this ever make it to proposal stage?

It seems like there is significant momentum towards keeping in Alpha phase (which we are in right now) until the ApereoCamp in January and then branching a Beta. 

Does someone want to rephrase this in the form of a proposal? 

Cheers,
Neal

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

On Oct 31, 2013, at 10:07 AM, Anthony Whyte <arwhyte at umich.edu> wrote:

> 
>> There are some things that require the code eventually be frozen and the trunk get cut. I'd like to see a date where we cut and stick to that, calling that a beta rather than an RC.  I'd propose this date to be the Apereo unconference at the end of January 3 months from now. We need this date so translation on the new features can start, help documentation updated (planning on a new help system) and something that known stable can easily be tested.
> 
> 
> + 1.  In earlier conversations with Sam, John Bush, Seth and Ian Dolphin the idea of leveraging the ApereoCamp as a F2F opportunity to hack, talk strategy as well as focus on locking down (freezing) the next release gained a good deal of traction.
> 
> Anth
> 
> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
> 
> 
> On Oct 31, 2013, at 9:52 AM, Matthew Jones wrote:
> 
>> I like most of this proposal, I just have the concerns that were brought up earlier on other calls/emails.
>> 
>> We're going to have the issue of velocity intersecting with constraints. There has to be sometime when we say "no more new features that's it", what time is that? This is to Neals point about the schedule. There are some things that require the code eventually be frozen and the trunk get cut. I'd like to see a date where we cut and stick to that, calling that a beta rather than an RC. I'd propose this date to be the Apereo unconference at the end of January 3 months from now. We need this date so translation on the new features can start, help documentation updated (planning on a new help system) and something that known stable can easily be tested. I feel that waiting until the proposed RC in March/April is too long to wait for this. Also most people should be back from the holiday downtime and committers mentioned will be back to their regularly scheduled jobs by then. 3 months feels to me like a good time for all this to come together as a balance between holding features planned for 11 off in branch(es) and getting features for 10 in.
>> 
>> With the "branch is 10" plan, we fully expected major new features like LTI 2.0, dashboard and new lessons changes would still make it in 10. Though I'm also fine with leaving trunk as is until a later time, as long as Neal can watch the medium+ size features committed,  update the release team weekly on what's going on in trunk and mark these to be specifically reviewed/QA'd later. We know about the major features we expect to still see completed before the release of beta (new previously discussed tool additions and major tool upgrades) but something else might slip though. 
>> 
>> There isn't really a straight comparison between OAE and Sakai because OAE had dedicated developers on the core fixing blockers and criticals. Sakai has contributors from SCA's and EDU's who will generally prioritize blockers but are highly unlikely to get through the ~100 issues marked as critical. The best way to tackle that problem first is to spend time in small groups to re-prioritize these criticals like we had in the past. I'd bet about half could either be closed or aren't really criticals, but that is also a few hours a over a few weeks of effort.
>> 
>> I also want to see good velocity on this. It's been a year and a half between 2.8 -> 2.9 (Spring 2011 -> Fall 2012) and now a year and a half between 2.9 and 10 (Fall 2012 -> Spring/Summer 2014). If we got Sakai 11 out by Spring/Summer 2015 on a quicker/predictable schedule then we'd have less worry about features not making the release.
>> 
>> 
>> On Thu, Oct 31, 2013 at 9:31 AM, Charles Hedrick <hedrick at rutgers.edu> wrote:
>> I don’t quite understand. There’s going to be something like 6 months between the start of 2.10 and release. I may well want to add new code during that time that don’t make sense to go into 10. I need a place to put it. Am I the only one? I wonder if we aren’t going to end up with many tools having to create “future” branches, and then once 10 is branched find some way to rename them to trunk.
>> 
>> If LTI isn’t ready for 10 at the same time as everyone else, I’d be happy to see them branch later. 10 is just an externals file, so it should be able to adapt to some tools using trunk and some branches.
>> 
>> Speaking for Lessons, I’m going to have a fair amount of new code for 10. It will need to get QA’ed. It’s going to be hard enough to arrange that without other changes creeping into trunk at the same time. I need to do a feature freeze shortly.
>> 
>> 
>> On Oct 31, 2013, at 1:14 AM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>> 
>>> I'm on board with staying on trunk until the first RC. I've said previously that the dates for the first alpha tag was far too early. This gives us time to work through some more proposed additions/updates for trunk too and directly relates to the velocity topic you raised. It also reduces the time people spend time on releasing at this very early stage, instead concentrating our efforts when they are needed.
>>> 
>>> We would need to make sure things aren't too wild on 'RC Day' though. If we give people regular notices that RC Day is coming hopefully they will play nice and have things in a good state ready for a branch.
>>> 
>>> cheers,
>>> S
>>> 
>>> 
>>> On Thu, Oct 31, 2013 at 10:52 AM, 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
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> 
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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/20131112/fd7f7c89/attachment-0001.html 