[Deploying Sakai] [Building Sakai] Trunk: ui package proposal

[Matthew Jones]

Seth,

It was *very weird* because I was talking to Noah about exactly the same
thing right before you sent this. Then we both went back to our desks to sit
down and he was like, "Hey Matt did you read the email from Seth?" I was
grumbling with him how the independent releases seem to be good things, but
when the kernel broke off it essentially became like managing 2 separate
releases for us, since we have a number of patches against the kernel, some
local & some backports. Before we could release 2.6 Dave quickly hacked
together a simple script for the kernel builds while I worked on getting the
trunk going. This had to be separate from the older xml/ant/maven based
build process we have for the regular builds.

The custom project (kernel) script had to:
- Read some configuration properties
- Check out the project externals (kernel in this case)
- Apply the specified list of patch files (aborting if any conflict)
- Update the pom.xml's to be a new version tag (so the build would use this
rather than one in the repository)
- Compile the kernel (failing if it fails to compile)
- Deploy the artifacts to our local maven repository
- Compress and publish source jar for the developers to use in eclipse for
debugging
- Save the build summary report

It probably could do more, but this was sufficient. It actually is close to
what the other build process does, except that replaces a few more
files/strings.

Every one of these independent releases that will have to be locally
maintained/modified will likely require a consistent workflow similar to
this. It is unlikely that this will be able to be maintained solely with
maven. I was looking at apache buildr or possibly writing a simple helper in
a jvm script language (scala/jruby) to manage this. We need to make it
easier to have customised local builds.

Whether an institution wants to keep all of their sources in local git/svn
repo, apply patches on top of the Sakai sources or something else, this
would be the next step after a installing a binary release. Possibly the
parts you need to patch (like strings) could be identified and replaced with
properties or with providers. This wouldn't be possible for everything
though.

If it's any reassurance Seth, we've been thinking about and working on the
problem at Michigan. I certainly do want an easier, more reassuring and
hopefully standard release process for custom builds than what currently
exists in the community. ;)

-Matthew

On Mon, Nov 9, 2009 at 5:40 PM, Seth Theriault <slt at columbia.edu> wrote:

>
> [Cross-posting to the production list]
>
> So that folks are aware, there are now several packages (kernel,
> edu-services, Samigo, etc.) with "independent release" status
> being readied for 2.7. While this approach offers some benefits,
> I fear there is the potential for increased work for deployers
> and more production-minded folks as a result.
>
> Why? Because for every package that attains "independent release"
> status, deployers who have local changes or patches or
> differences now MUST build and deploy their own versions of the
> affected package. As more and more "core services" packages are
> created, it is more and more likely that deployers will have to
> do this with as-yet-unknown effects.
>
> I'll give you a simple example with Samigo (which is going
> independent). Locally, Samigo is not known as "Tests & Quizzes",
> but rather, "Test & Quiz". This requires 3 patches, one of which
> is in the Help documentation. I now MUST build my own version of
> Samigo to apply this type of change.
>
> Perhaps we could slow the move to independent releases a bit in
> advance of the main 2.7.0 Sakai release and see what effect, if
> any, the new "independents" have on local deployment work.
>
> Seth
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20091109/a3c5d728/attachment.html