I've generated the Sakai 2.5.3 release artifacts and final tag and updated the release page.  I've tested (lightly) the sakai-demo-2-5-3.tar.gz, sakai-src-2-5-3.tgz and the sakai_2-5-3 tag, the latter two with a fresh Tomcat 5.5.26, empty MySQL 5.0.51 database and an empty .M2 org/sakaiproject repo.  The demo runs and the source artifact and tag both build and start up in Tomcat.

As I write my tag builder script is busy cranking out an RC 03 tag for the upcoming Sakai 2.5.3 maintenance release.  The tag was cut from the 2.5.3 branch which was itself earlier generated from the 2.5.x maintenance branch.  Unlike previous beta and RC tags that were created directly from the *x branch using a single SVN revision number (e.g. 2.5.x r48404 for the ill-fated 2.5.1 release), 2.5.3 represents a targeted approach that provides fixes to specific sets of tools and services.  This strategy allows QA to better harness their resources and focus their testing on limited areas of the code base.  2.5.4 and succeeding maintenance releases will reflect this pattern. 

Regarding the 2.5 maintenance series, 2.5.1 included over 120 fixes but was never released officially due to the discovery of a nasty portfolio bug during final testing of the release artifacts.  2.5.2 was the ... Read More »

The presentation tool is a core tool that provides the capability to upload and display sets of images to users.  However, I sense that this tool is little used by the Community.   The University of Michigan, for example, stealthes the tool since there is little interest in it given its current capabilities.

For 2.6.0 I'd like to suggest that we remove the tool from the release.   This does not necessarily mean that we need to go through the process of physically moving the files from the main SVN repo to our contrib repo, although this could be done.  Rather, we could simply modify the Sakai .externals file to exclude it from /trunk and maintenance branch check outs as well as generate release artifacts without it.

Indeed, I might well be wrong about the size of the Presentation Tool's institutional user base.  If so, it would be premature to exclude it from the release.  But if it ... Read More »

Tueseday I finished generating the 2.5.2 source, binary and demo artifacts, javadocs, taglib docs and poms/jars for the Sakai Maven2 repo, cut the final 2.5.2 tag and prepped the Sakai 2.5.2 release page. Artifact testing has so far proved positive so the release should be ready for public consumption.

Sakai 2.5.2 succeeds the ill-fated 2.5.1 release that included a nasty portfolio bug discovered only after I had generated the 2.5.1 release artifacts. A disappointing find to be sure but issues of this sort are bound to happen from time to time and it helped set a precedent of quickly responding to the issue, incrementing the version number by one and cutting a new release.

Bring on 2.5.3.

When commiting code changes to the Sakai SVN repository I forget occasionally to include the relevant Jira "SAK" issue number in the log entry.  We use the Jira Subversion plugin and neglecting to include the Jira reference in the commit log message prevents the commit info from being picked up by Jira.

Good

svn commit -m "SAK-13784 update Tomcat version to 5.5.26"

Bad

svn commit -m "update Tomcat version to 5.5.26"

So if you are bad like I am sometimes, issue the following svn command to correct the log, including the original commit's revision number and the updated log entry:

svn propset - ... Read More »

There's a thread on the Sakai pedagogy list called "Content Authoring" that's morphed into a discussion regarding Sakai's relative openness as an open-source project.  During the exchange there was a mention of Ohloh by Chuck Severance which drew a response from one participant in the discussion asking to see richer Ohloh profiles of Sakai core/contrib committers.

Since we started enlisting Sakai projects on Ohloh, 71 core and 87 contrib contributors have been tracked (the latter group also contribute heavily to Sakai core projects).  Only a fraction of the profiles listed include any information beyond the basic developer X as represented by a portion of their email address has made Y commits since Month Z.

Creating an account permits developers to provide additional inform ... Read More »

The University of Cape Town's Sakai Vula gateway features a collection of graphic art produced to both promote Vula and engage students, faculty and staff in the process of online learning.  There are ten images in the collection, one of which is loaded randomly whenever the gateway page is requested. 

"V is for Vula" in red, black and yellow is particularly striking; David Horwitz tells me the design is inspired by an old United Democratic Front (UDF) anti-apartheid poster.

Another image I find quite creative spells out "Vula" (meaning "open ... Read More »

North-West University (South Africa) and Psybergate are engaged in an interesting project to develop "offline" capabilities for Sakai.  Codenamed "Solo", the application will be contributed to the Sakai Community upon its release. 

The idea behind Solo is to create a "disconnected" version of Sakai  that would permit students to better control  their internet usage  in bandwidth-challenged environments like South Africa. NWU's initial thinking involves distributing a Solo client application and set of course materials to their students on a CD/DVD.  The client would permit students to sync with their Sakai course sites when new or updated course materials become available.  The offline cl ... Read More »