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

Wed Oct 30 22:14:53 PDT 2013

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131031/6086bbdd/attachment.html 