[cle-release-team] [sakai2-tcc] Emerging consensus to focus on 2.10

Wed Sep 11 08:39:38 PDT 2013

My latest thinking, based on what I believe I am hearing, is this:

* Trunk has a lot of good stuff in it. Let's get it out to the community as soon as possible so folks can start taking advantage of it. Let's not keep it hidden and locked away.

* We might want to get some bigger things into Sakai, that will have more of "wow" factor, meet pedagogical needs, attract additional resources, etc. Let's start figuring out what those things are and what folks are willing to work on. Some of that still might get into trunk before we branch and some might be for the release after. 

This seems somewhat independent of the discussion of the naming issue. 

I'm starting to think through potential schedules for releasing the stuff in trunk. At some point we will need to pick a name (I presume when we branch it?). More importantly we will need branch managers. Please be thinking about that and whether this is something you could/would be willing to take on and if your institution is willing to donate some of your time to help in this effort. If you would be interested but might need some help transitioning to this role, perhaps we could get one or two of the experienced devs to mentor. Just a possibility. Please let me know and we can explore off-list.

Part of tomorrow's TCC - CLE meeting will be helping figure out the schedule, or what factors to consider in building a schedule so that I can come up with a strawperson schedule we can use. I don't think we have to finalize a schedule to get started, but it could help with focus and goals. Of course, no decisions will be made on the call, and I will push the discussion back to this list. 

If anyone would like to propose a schedule, it does not have to come from me, but I'll work towards one if nobody else steps up to do this.

Cheers,
Neal

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

On Sep 9, 2013, at 1:34 PM, Noah Botimer <botimer at umich.edu> wrote:

> Personally, i wouldn't preclude those items, but I would say that they have "something to prove". LTI 2.0 is a complete, uncontested win. And something like Dashboard concerns me much less than a new build process. It's in the production fire now, and everyone knows how to turn tools/features on/off if they need, so ship it. You can't turn off a revamped build process -- it would couple these other *great* steps forward with retooling your ops team -- bad decision.
> 
> We have made enough half-steps on builds that I am thoroughly "over it". If the overall nature of building/releasing should change, it should change once for the next three years, and should be well tested before being inflicted upon developers and eventually installers.
> 
> Thus, my push for Gradle, which could be tested literally in place and alongside our existing builds, changing nothing for those who aren't ready, incrementally mapping out a nice place to live. And yes, I think it is definitely time, but I am done with "fixing" our extremely over-complex Maven builds.
> 
> Aside from just dropping all of the indies/assemblies, I am opposed to any "cleanup" of our Maven builds, especially prospective changes. Other than the assemblies, I think overhauling the Maven build is the worst possible inclusion for the next major release, conflating landmark features with technical upheaval.
> 
> Thanks,
> -Noah
> 
> On Sep 9, 2013, at 12:48 PM, Anthony Whyte wrote:
> 
>>>> . . . my real desire is to start work *today* on the next major release.
>> 
>> 
>> Yes
>> 
>>>> . . . start working on a major release based on what we have in trunk today.
>> 
>> 
>> No . . . if by your trailing qualifier you are suggesting we preclude the option of refactoring work (build simplification, for instance) or upgrades like LTI 2.0 or at least evaluating the readiness of new user-facing functionality such as dashboard. 
>> 
>> 
>> Cheers,
>> 
>> Anth
>> 
>> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
>> 
>> 
>> On Sep 9, 2013, at 10:47 AM, Noah Botimer wrote:
>> 
>>> +!
>>> 
>>> Thanks,
>>> -Noah
>>> 
>>> On Sep 9, 2013, at 10:45 AM, Beth Kirschner wrote:
>>> 
>>>> I actually think we are in agreement - I was conceding the naming convention of 2.10 vs 4.0 in my email, but my real desire is to start work *today* on the next major release. I prefer 4.0, but am willing to throw the naming preference under the bus if that's what it takes to start working on a major release based on what we have in trunk today.
>>>> 
>>>> Neal, would you be willing to put together a straw-man proposal for a 4.0 release timeline prior to Thursday? I'd like to see us move the discussion to setting milestones, including when to branch for 4.0.
>>>> 
>>>> - Beth
>>>> 
>>>> On Sep 9, 2013, at 9:50 AM, Charles Severance <csev at umich.edu> wrote:
>>>> 
>>>>> I think that Noah is wrong and disagree with Beth below.
>>>>> 
>>>>> We should expect a relatively small 2.9.4 release that is essential/critical bug fixes only and then a 4.0.  Starting immediately we should work towards a trunk-based 4.0 release and move 2-9-x into "maintenance mode".  We need to spend some time working on trunk and then begin to focus nearly all of our efforts of dev-testing and QA of trunk and put in as little effort as we can on 2-9-x.  Starting *today* - not nine months from now.
>>>>> 
>>>>> To those who think that we need yet-still-more new features before we are "worthy" of a 4.0 - you are *could not be more* wrong.
>>>>> 
>>>>> I would suggest that you download Sakai *2.0*, bring it up and then compare it to trunk or even 2.9.3 in terms of features, performance and look and feel.   What we have in trunk and even the 2.9.3 release bears so little resemblance to the Sakai 2.0 release that we probably should have called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0 is completely misleading and badly confusing to the marketplace.  
>>>>> 
>>>>> Please explain to me how a 2.10 release is somehow a maintenance release of that 2005 software we called "Sakai 2.0".
>>>>> 
>>>>> If you want to get a sense of what the lack of a major new version is dong to us all - look at this Twitter thread:
>>>>> 
>>>>> https://twitter.com/PhilOnEdTech/status/374947773210062848
>>>>> 
>>>>> This sucks for commercial purveyors of Sakai and sucks for on-campus people trying to advocate that Sakai was not dead three years ago.  Sakai is still one of the best LMS's on the market right now and its vector is strong.  Three years ago members of the Sakai community were our own worst enemy.  We formed the TCC so we would have leadership that would not be "our own worst enemy" - but if we degrade into group-think and convince ourselves that the next major release needs to be labelled a minor release - we *have* become our own worst enemy.
>>>>> 
>>>>> We as insiders all have our little pet peeves as to what we should fix.  That is normal - all projects have that.   Things like when to declare a major new version should not be blocked by people trying to force others to work on their own pet peeves.
>>>>> 
>>>>> It time to move on.
>>>>> 
>>>>> /Chuck
>>>>> 
>>>>> On Sep 9, 2013, at 8:32 AM, Beth Kirschner <bkirschn at umich.edu> wrote:
>>>>> 
>>>>>> It is now September -- we have been debating this since the conference in June. If we don't very quickly come to consensus on a release schedule, we can pretty much forget about a major release in the first half of 2014. There is a lot of good stuff in trunk that should be QA'd and released. The longer we wait on getting trunk QA'd and released, the more problematic it will be to put out a stable release. More code change == more risk of bugs. Now is not the time for indecision. Nor is it the time for putting more into a release that's not in there now. I support Noah's approach of a 2.10 followed by a 4.0.
>>>>>> 
>>>>>> - Beth
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> 
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130911/22d74d83/attachment-0001.html 