[sakai2-tcc] Improving the release process

[David Horwitz]

While I support the goals, what is unclear to me is how undoing the indie process and reverting to a monolithic build is going to simplify the release process. The indiefication was started with this in mind, while I agree we where not as successful as we hoped these where the very issues we where aiming to facilitate with this process.

D



On Tue, 2013-04-02 at 09:20 -0400, Beth Kirschner wrote:


I agree that the experiment with indies has failed their intended goal and doesn't reflect how Sakai is currently maintained. I worry about the effort to once again re-invent the process, but in general I'm supportive. If we have frequent Sakai releases, this could negate the need for those modules that truly do meet the ideals of an indie (e.g. Lesson Builder, Basic LTI, etc.).

- Beth

On Apr 2, 2013, at 7:13 AM, Steve Swinsburg <steve.swinsburg at gmail.com<mailto:steve.swinsburg at gmail.com>> wrote:

> Hi all
>
> I'd like to have a discussion around improving the release process with respect to having more releases per year and making the release process itself faster.
>
> In most cases, the indies have failed in their intended goal. That is, allow off cycle releases. This would have been a perfect process if all modules were individually maintained and actively developed as project teams could release as they desire. Some projects did this well but for most there was no use. They were versioned along with the main CLE code but required an extra couple of steps to release.
>
> Coupled with a lot of deployers wanting to have the source for patching or some other reason, it just meant more overhead for doing a local build, and the creation of the -all releases and a lot of confusion about where the source code was, how to pull it in and modify it.
>
> People expect all of the source to be there in a checkout of an open source project, it wasn't and it was kind of odd - "but the modules are binaries in the repository, unzipped at deploy time, etc etc".
>
> What follow are numbered tasks that I believe need to occur. They come from solid experience in implementing this process for over twenty applications coming together into one final product. They are not yet formal proposals until we discuss. I've just numbered them for clarity.
>
> Task 1: Scrap all indies, re-version (if appropriate) back in line with the CLE versions, and clean up the externals and poms etc.
>
> Task 2: The speed of releases must increase. We cannot have a fix committed the day after a maintenance tag is released, for it to sit there for months until the next big release happens. We should be able to make a minor release quickly. This absolutely must occur if 1 goes ahead.
>
> Task 3: To facilitate 2, we must have the branch in a constantly releasable state. That will mean no dependency on snapshot artifacts within tools. This needs a bit more thought but is out there for discussion. I believe with a bit of top level pom work we can make this happen. One thing to keep in mind is offline builds.
>
> Task 4: The deploy to Maven Central needs to be expanded. It is currently only being done for indies [1] but needs to be done for all artifacts, as per 2.8 and earlier releases (though they go to the Sakai maven repo). This allows contrib projects to build properly being able to find the correct versions of the artifacts they need.
>
> Task 5: Remove dependency on Jenkins as a release platform. Unless Jenkins can be setup as a simple server that runs a build and kicks the artifact out, then it is too complex and you might as well use the command line. Logging in to the server, editing scripts [2] or anything else that needs to be done is silly. And if something goes wrong, we need to troubleshoot the jenkins server. A set of clear instructions should be all that is required.
>
> Task 6: Rationalisation of the base and master poms should occur where necessary. This will also provide clarity for contrib projects which depend on a mix of base and master poms.
>
> I propose all of the above with a view for implementation in 2.10.
>
> In discussing, I beg that people refrain from turning this into a resourcing/volunteering issue and discuss the technical issues at hand. Who does what can come afterwards.
>
> Finally, I make the above comments, suggestions and potential solutions purely because I want to see this process be improved, as a developer, deployer and someone that does the releases. And that is all.
>
> regards,
> Steve
>
> [1] http://central.maven.org/maven2/org/sakaiproject/
> [2] https://confluence.sakaiproject.org/display/REL/Sakai+CLE+release+guide
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org<mailto:sakai2-tcc at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



________________________________
UNIVERSITY OF CAPE TOWN

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130403/20d37b5c/attachment.html