[WG: Sakai QA] Release proccess [Request for inclusion in 2.6.1: SAK-16416]

[Matthew Buckett]

2009/6/6 David Horwitz <david.horwitz at uct.ac.za>

>
> I personally think we have reached a juncture where we need to rethink the
> way we think of and handle Sakai releases. The problems I see are:
>

> We lump everyone in the same risk profile. Different users have different
> tolerances of risk - some will run contrib tools early others wont. At the
> moment its very difficult for a user with a high tolerance of risk to run
> new code early. We're in essence breaking the OS mantra of  "release early,
> release often", and loose the informal QA we'd get from these users. I think
> the new product development  process  addresses part of this - and we're
> going to have to think about in the K2 world - lets start adopting
> practices  that make our life easier.
>

I think you're right on the money and this is the right direction to go. We
currently have a few small projects that are added to our build from
deployed artifacts.

While I don't think radical change is possible I do have some practical
> suggestions:
>
> 1) We break the dependency of Sakai tools on master for building. This is a
> bizarre pattern that gives every tool a dependency on every other tool.
> Tools should inherit from the kernel and where more complex dependencies are
> needed we can define and release poms to meet the needs of developer (e.g.
> Sakai-gradable-velocity-tool.pom)
>
> 2) We identify stable pieces of code that are not deployed to tomcat
> themselves but are used by other Sakai tools and cut binary releases of
> them. There are several of these, mostly libraries and poms in velocity and
> JSF but I'm sure there are others.
>

My only concern here is how you make sure that the tools you deploy are
compiled against the correct libraries deployed into shared. At the moment
when making a release I know all my tools are compiling against the correct
API as it's the one that's just been built earlier in the build.


3) Learn from the K1 experience - this has worked well - is there other code
> we could do this with? I'd like to tentatively suggest we may want 2 other
> bundles that provide stable widely used functionality:
>     1) Common services (commons project (SakaiPerson & Type Service,
> Taggable Service, Privacy Service, Email Template service)
>     2) Common edu service (Course Management, Content Review, Gradebook
> Service(?))
>
> 4) identify very stable projects (such as the admin tools) and tag them
> with their own version and leave them between releases. For instance its
> been 8 months since a change to the Admin user tool, bar translation updates
> and housekeeping.
>

I'd also hope that contrib tools would produce release artifacts into a
maven repo, as in our local build we have several unpatched contrib tools
that just slow up our build.

-- 
 Matthew Buckett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090619/f3041a10/attachment.html