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

Thu Oct 31 06:42:11 PDT 2013

Yes, I believe you are the only one.  I can't think of any other tool that
is still rapidly adding features in a similar fashion to Lessons.

I believe the traditional feature freeze in late September happened years
ago because so many large features were still being added, and the
community needed a strong way to draw the line and push some features to
the next major revision.  I don't think we suffer from the same problem
anymore and working from trunk allows us to avoid spending time on
branching and merging until later in the cycle.

I think feature branches makes sense for Lessons, although I would ask: are
these features you really don't want to be QA'ed until 2015 and released in
mid-2015?  Are they not features that can be refined and QA'ed over the
next six months?

--Sam

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