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

Noah Botimer botimer at umich.edu
Wed Sep 11 10:41:35 PDT 2013 

Sounds good to me. A suggestion:

The commit-to-trunk-and-flip-merge-flag pattern running for a full alpha-beta-rc cycle is kind of lame, especially during the earlier bits with high activity. It puts an artificial embargo on changes to be tested by depending on an artificial role (all of our branch managers have been developers doing other fix-it work simultaneously).

I see two high-level patterns in response to this:

	1. Maintain that trunk is to-be-released until some chosen, later stage (e.g., beta or RC, when the release branch would be made) -- experimental things or items that need not block the release happen in a branch until ready.

	2. Remove the merge blockade for developers doing the to-be-released changes and have them merge from THE FUTURE (trunk) to the release branch at the time of completion -- these are the best people for merging and this relieves some of the overstrain on QA where there is a two-stage test that often delays and compounds merging load.

Although pretty similar in shape and outcome, my preference would be to favor scenario #1. We should be in the habit of working on feature branches. That it can be difficult now is largely a side effect of some other process pathologies worth fixing on their own. I will, again, point to KNL-515, which was a huge change kept current with trunk over months with minimal effort [1]. This is pretty standard fare with DVCS, à la fork & pull.

Thanks,
-Noah


[1] Please do note that the extreme breadth made the svn:externals workflow untenable, so the minimal effort was only practicable with a unified working copy (Git layered over an SVN wc). Most changes are much more narrow and would work fine with standard SVN branches, though the Git workflow scales nicely.

On Sep 11, 2013, at 11:39 AM, Neal Caidin wrote:

> 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
> 
> _______________________________________________
> 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/87d71443/attachment-0001.html

More information about the cle-release-team mailing list