[cle-release-team] Sakai 2.9 release process

[Beth Kirschner]

I'd like to summarize some recent off-list discussions in an effort to  
move forward the Sakai 2.9 build & release process. But first, I think  
we need to not lose sight of the primary goal, which is to release 2.9  
alpha/beta tags quickly and often. It's now mid-November and this  
release team has not directly released any tag. We've just removed  
several road-blocks to making this happen (thanks all!). I think the  
next steps is that the release team needs to take action, make  
decisions, and start putting out regular tagged releases for QA.  
Additionally, we need to decide on updated milestones for the 2.9  
release, starting with when to branch. I'd like to suggest that we  
discuss _and_ make decisions no later than this Thursday's Release  
Team meeting that will result in the following:

1) a new alpha tag build started this week
2) a target date for the first branch and beta tag

Primary goal: Release 2.9 alpha/beta tags in a timely, efficient manner.

Secondary goals:
	* Clean up the release process enough to automate (at least most of) it
	* Rationalize kernel-util (initial testing of this proved successful)
	* Break calendar/assignments cross-dependency (SAK-21389 - fixed)
	* Break courier/presence cross-dependency (SAK-21397 -patch attached)
	* Rationalize kernel, entitybroker, common, edu-services and sakai- 
basic-tool, sakai-standard-tool, sakai-common-tool, sakai-edu-tool
	* Break awkward versioning/release constraints between kernel/ 
framework and indies
	* Explore using a real repository manager and automated build server
	* Balance doing the best possible thing, the smallest possible thing,  
and resources available (avoid partial/piecemeal/long transitions)

Remaining proposed work to achieve the primary goal is as follows:

1. Move kernel-util to shared.
2. Combine the base pom.xml and master/pom.xml into one, perhaps  
called sakai-parent (following the Jasig model for uPortal).
3. Possibly remove purepoms entirely, all indies then inherit from the  
sakai-parent pom.
4. If not 3, then collapse these into one pom, perhaps called sakai- 
indie or similar.
5. Migrate Entity broker into the kernel
6. Combine common and edu-services into  a single package

Additionally, we also discussed as a short term way forward to just  
start cutting [alpha] releases based off some revision of nightly.

Say if we wanted the next alpha to be next Tuesday, then what revision  
was Monday midnight (time zone of the source control server so EST)  
that would be the package what is deployed to QA servers. We could  
call next weeks
sakai-2.9.0-a02-2011-11-15 rXXXXXX

And just go with that until actual release candidates. Once we get  
there, the indie dependency tree won't have any cycles or other  
problems, we shouldn't have to rebuild all of the indies, and make it  
much easier to run the script to pump out a regular release.

The only downside is that regular people if they want the source won't  
be able to check out the alpha tag.