[sakai2-tcc] Proposal: eliminate all indies, re-version trunk to CLE 4.0

Steve Swinsburg steve.swinsburg at gmail.com
Tue Jun 18 05:25:45 PDT 2013 

If I was there I would have definitely brought it up, so just assume it was
discussed also ;)

cheers,
Steve


On Tue, Jun 18, 2013 at 10:23 PM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> I want to echo pretty much all of these (and in a sign that these are
> good points, they all came up at the conference meeting... except the
> odd numbers one.... but close enough).
> :-)
> -AZ
>
>
> On Tue, Jun 18, 2013 at 8:01 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
> > A few late night thoughts on the 4.0 jump.
> >
> > 1. I've never liked 2.10 as a version, once you get into double digits it
> > looks weird and is almost like 2.1.
> > 2. We could go to 3 but there is too much confusion with Sakai3/3akai.
> Also
> > 3akai is still being used as the OAE fronted name.
> > 3. Re-versioning all projects means that in order to avoid conflicts with
> > existing versions and to not go backwards, we need to go forwards, and
> the
> > next version is 4.0. We already have a 3.0 for msgcntr so we can't go
> back
> > to 2.10 for that without it being super confusing.
> > 4. CLE 4 has a cool ring to it.
> > 5. No one likes odd numbers?
> >
> > cheers,
> > Steve
> >
> >
> > On Tue, Jun 18, 2013 at 9:53 PM, May, Megan Marie <mmmay at indiana.edu>
> wrote:
> >>
> >> Is 4.0 supposed to follow 2.9.3?    I’d like to see some justification
> for
> >> jumping to this version.
> >>
> >>
> >>
> >> From: sakai2-tcc-bounces at collab.sakaiproject.org
> >> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On Behalf Of Steve
> >> Swinsburg
> >> Sent: Tuesday, June 18, 2013 12:58 AM
> >> To: Anthony Whyte
> >> Cc: sakai2-tcc Committee
> >> Subject: Re: [sakai2-tcc] Proposal: eliminate all indies, re-version
> trunk
> >> to CLE 4.0
> >>
> >>
> >>
> >> Wow 4.0, interesting. I can see the CLE4 logo already! Yes I would like
> to
> >> help. We have the sakaiproject org in github, Noah could possibly move
> the
> >> repo there before we begin? It's almost like how nakamura was always a
> fork
> >> of ieb. But it's transient so it doesn't matter I guess.
> >>
> >>
> >>
> >> Let's flesh out what tasks need to be done so we can take parts and get
> it
> >> done.
> >>
> >>
> >>
> >> Cheers
> >>
> >> Steve
> >>
> >> Sent from my iPhone
> >>
> >>
> >> On 18/06/2013, at 7:04, Anthony Whyte <arwhyte at umich.edu> wrote:
> >>
> >> The proposal below plays off our discussions in San Diego relative to
> >> working towards a simplified build/deploy process.  It represents an
> >> incremental step but I think warranted given the failure of the indie
> >> approach to capture the imagination of the Sakai Community and the
> attendant
> >> "version" confusion often encountered by local deployers attempting to
> track
> >> and manage CLE release changes.
> >>
> >>
> >>
> >> The proposal represents a first step in the
> simplification/rationalization
> >> process.  I can make time to do the work starting this week, if it meets
> >> with your approval.  If Steve and Matt have any time to help all the
> better.
> >>
> >>
> >>
> >> PROPOSED CHANGES (limited to trunk)
> >>
> >> a. All CLE modules will be versioned 4.0-SNAPSHOT (no exceptions)
> >> b. All CLE module base poms will inherit from the master pom as their
> >> <parent>.   The Kernel and CLE master pom will retain their oss-parent
> >> <parent>.  The CLE base pom will continue to inherit from the master
> pom.
> >> c. All CLE module assembly code will be deleted and references to
> assembly
> >> <module> will also be removed from module poms (e.g.,
> >> <module>basiclti-assembly</module> will be deleted).
> >> d. All CLE module poms that include explicit version references to Sakai
> >> dependencies will be updated.  When appropriate I'll swap in Maven
> property
> >> variables.
> >>
> >> e. Eliminate 34 CLE module version <properties> from the master pom
> >> rendered redundant by the switch to a single version for all CLE core
> >> modules.
> >>
> >> f. https://source.sakaiproject.org/svn/sakai/trunk/jstl-shared-deploy/
> >> will be deleted (rendered redundant by deploy/ poms)
> >>
> >> g. freebie: hybrid module will be eliminated from .externals and base
> pom
> >> build profiles.
> >>
> >>
> >>
> >> WORK WILL BE DONE IN GITHUB
> >>
> >> I will do my work in a local branch off my local fork of
> botimer/sakai-cle
> >> [1].   I'll create a branch called "no_indie" and make my changes there
> in a
> >> manner similar to the way Noah handled his spring work.  Noah keeps his
> repo
> >> sync'd with sakai-trunk changes and I will do the same with my local
> branch.
> >> I prefer to make all changes at once, test, and then provide a single
> patch
> >> that can be committed to SVN trunk.
> >>
> >>
> >>
> >> OUT OF SCOPE FOR THIS PROPOSAL (but still on the table for CLE 4.0)
> >>
> >> Base/Master pom rationalization.  I recommend that we consider revising
> >> the base pom in a way that we end up with a pom not unlike the
> >> org.apache.apache pom,[2]  Everything else we move to the master pom,
> which
> >> would inherit from the base pom, which would inherent from the
> oss-parent.
> >>
> >>             oss-parent
> >>
> >>                         Sakai base pom
> >>
> >>                             project info, repos, distribution
> management,
> >> plugin management, plugins
> >>
> >>                                     Sakai master pom
> >>
> >>                                 build profiles (from base pom),
> >> properties, dependencies, build, reporting
> >>
> >>
> >>
> >> Note: changing the order of inheritance as suggested about would impact
> >> some contrib projects negatively.  We would need to either be prepared
> to
> >> help patch such projects or sufficient warning and simple steps on how
> to
> >> fix the <parent> element of contrib project's base pom.
> >>
> >>
> >>
> >> IMPLICATIONS
> >>
> >> 1.  We return to a monolithic release process, circa Sakai 2.5.  Leaving
> >> aside Ian's reasons for creating kernel as the first indie, a
> commitment to
> >> shorter release cycles should provide a counterweight to the original
> >> rationale for creating tool indies, i.e., the need for off-cycle
> releases of
> >> important bug fixes or new functionality in order to compensate for
> overlong
> >> CLE release cycles.  However, without a commitment to shorter release
> >> cycles, eliminating indies could prove counterproductive.
> >>
> >> 2.  Faster downloads (no assemblies); consistent build/deploy behaviors
> >> for all modules (I should note that this has been addressed in trunk by
> >> importing the sakai-trunk-all approach).
> >>
> >> 3.  Elimination of version confusion.  All modules, all one version.
> >> Simple.
> >>
> >> 4.  A lag in the elimination of Jira confusion.  The SAK project can be
> >> bulked up with additional components, which if you are working on the
> latest
> >> stuff represents a gain; however, as Matt notes below, the Indie Jira
> >> projects will have to be retained for tracking earlier versions.  So no
> >> victory can be claimed here.
> >>
> >> 5.  Local build script changes.  I imagine some schools have crafted
> build
> >> scripts that accommodate the indies.  These scripts will need to be
> changed
> >> (simplified).  So a local impact cannot be discounted.
> >>
> >> 6. trunk devs will need to need to a fresh check out and clean install
> >> when the poms are updated.  No biggie but it should be mentioned.
> >>
> >>
> >>
> >> Feel free to add other implications or raise a material objection.
> >>
> >>
> >>
> >> Cheers,
> >>
> >>
> >>
> >> Anth
> >>
> >>
> >>
> >> [1] https://github.com/botimer/sakai-cle
> >> [2]
> >>
> http://search.maven.org/remotecontent?filepath=org/apache/apache/13/apache-13.pom
> >>
> >>
> >>
> >>
> >>
> >> Begin forwarded message:
> >>
> >>
> >>
> >> From: Matthew Jones <matthew at longsight.com>
> >>
> >> Date: June 17, 2013 1:54:51 PM EDT
> >>
> >> To: Beth Kirschner <bkirschn at umich.edu>
> >>
> >> Cc: "sakai2-tcc at collab.sakaiproject.org Committee"
> >> <sakai2-tcc at collab.sakaiproject.org>
> >>
> >> Subject: Re: [sakai2-tcc] Is there any reason I should not change the
> LTI
> >> version in trunk to 2.10-SNAPSHOT ??
> >>
> >>
> >>
> >> Sending email on a weekend usually means it will get missed (or at
> least a
> >> delayed response). I'll usually draft my weekend emails and send on
> Monday.
> >> ;)
> >>
> >>
> >>
> >> And yea, it was discussed at the conference and there was some notes
> here.
> >> (Project organization and release process simplification)
> >>
> >>
> >>
> https://confluence.sakaiproject.org/display/TCC/2013+Apereo+TCC+Meeting+Notes
> .
> >>
> >>
> >>
> >> I read your email, Steve but haven't had time to respond to individual
> >> points. I believe I agreed 100% on the outline of the current
> >> problem/situation but wasn't sure about the solution. Really though any
> >> solution is okay with me and I agree the current process isn't feasible
> for
> >> the future. It's move of a question is who's going to put in the
> (supposedly
> >> volunteer) time to do it? Anthony said he'd look at it and I'd help
> him, but
> >> I'm pretty much booked with local work through the summer, so likely
> >> wouldn't be doing anything extensive until late September/October. I
> think
> >> this would be too disruptive for 2.9 but the proof of concept could be
> done
> >> in trunk.
> >>
> >>
> >>
> >> As far as the 2.10 LTI question, you're free to set whatever version you
> >> want, but I think it would go to Steve's point and that doing this would
> >> mean that you wouldn't have LTI released tied to the releases of 2.10
> (when
> >> that starts getting released) so possibly a slower process than
> currently.
> >> And LTI has a separate project in JIRA which would need to be dealt with
> >> separately.
> >>
> >>
> >>
> >> There are really 2 types of indies. Indies that *are* indies because
> they
> >> some other indie needed the api's (or some other dependency) from it in
> >> order to build. You can't release the indie without having released it's
> >> dependencies. Most of the indies are this type and these *could* be
> >> collapsed easier because the version matches up better and they're
> still in
> >> SAK. However this would require everything including any former indies
> that
> >> had dependencies on these to be monolithic UNLESS the dependencies we're
> >> independently released (can't be done easily with maven any way I know
> of)
> >> or move them all to a separate project like edu-services is, something
> like
> >> sakai-apis.
> >>
> >>
> >>
> >> The indies that changed their version and have their separate JIRA
> project
> >> are harder, because if they're merged back into CLE, it will make it
> harder
> >> to track and report bugs against the old versions. If they remain
> outside of
> >> the CLE it will still make it hard to know that these exist as separate
> >> projects.
> >>
> >>
> >>
> >> Then we have the problem of msgcntr which is version 3.x already. To get
> >> around that, we either have to change the maven artifactId or groupId
> for
> >> msgcntr or we'd have to go with all of Sakai beyond 3.x (this was part
> of
> >> the 4.x proposal). So it might have to be 4.0 instead of 2.10 just
> because
> >> of msgcntr.
> >>
> >>
> >>
> >> Unless you were really looking for something to do, I don't think I'd
> jump
> >> it with LTI yet. I'm hoping those interested will have a chance to talk
> >> about this more in the near future, ideally finding a time with Steve
> if he
> >> is going to be doing some of that work. I agree with the goal, I just
> need a
> >> better roadmap for getting there.
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Jun 17, 2013 at 1:05 PM, Beth Kirschner <bkirschn at umich.edu>
> >> wrote:
> >>
> >> Steve -- at the conference we had discussed abandoning the indie
> approach
> >> to most, if not all tools, in the next major release -- currently to be
> >> called 2.10 (or 4.0?).
> >>
> >> Chuck -- I like the idea of changing the next version of LTI to 2.10.
> >> +1
> >>
> >> - Beth
> >>
> >>
> >> On Jun 16, 2013, at 6:45 AM, Steve Swinsburg <steve.swinsburg at gmail.com
> >
> >> wrote:
> >>
> >> > Well if it stays an indie then it becomes super confusing since the
> >> > version will at some point probably not line up with the reast of the
> actual
> >> > 2.10 projects. I discussed this in my proposal, ie purepoms at 2.8.9
> or
> >> > something when the Sakai release is 2.8.2 and other apps at 2.8.6.
> Head
> >> > explosion.
> >> >
> >> > So it depends if you want to have off cycle release. If not and it is
> >> > all to be rolled into the main release cycle then go for it.
> >> >
> >> > Was there any discussion on my proposal at the conference?
> >> >
> >> > cheers,
> >> > Steve
> >> >
> >> >
> >> > On Sun, Jun 16, 2013 at 2:26 AM, Charles Severance <csev at umich.edu>
> >> > wrote:
> >> > I figure no time like the present...
> >> >
> >> > Of course I would need to fix target versions in JIRA - but that would
> >> > be easy enough - there are only a few - so I could fix those by hand
> once I
> >> > got a 2.10 tentative version.
> >> >
> >> > Thoughts / comments??
> >> >
> >> > /Chuck
> >> >
> >> > _______________________________________________
> >> > 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
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130618/0dbbfd6f/attachment-0001.html

More information about the sakai2-tcc mailing list