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

[David Horwitz]

Hi Guys,

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.

We deal with too much code in the release. Sakai is huge and we don't
differentiate between code that hasn't changed over several release
cycles and code that is evolving.

We use maven very badly. When I look at how easy it is manage K1 versus
what I go through to put our production build together and what I seen
Anthony going through to do the Sakai release its obvious we could be
doing this way better.

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.

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.

5) Identify projects with a clear development team and drive (I'm
thinking here of OSP and T&Q) and engage those teams to see if they may
benefit from their own release cycle/versions (much like the kernel has)
As most of the issue verification on these 2 projects I've seen comes
from within those teams. The Sakai QA process becomes more of oversight
and due diligence process in these cases our role is to satisfy
ourselves that the code we include is good quality, and to support 
those teams in achieving this.

Regards

David

Seth Theriault wrote:
> Anthony Whyte wrote:
>
>   
>> We then update the 2.6.x poms version number to the next 
>> SNAPSHOT version (e.g., 2.6.2- SNAPSHOT) and recommence the 
>> cycle.
>>     
>
> Without commenting on the rest, I remind everyone that there is 
> an outstanding "proposal" to use a stable, non-incrementing 
> version for maintenance branches (like M2 in 2.5.x). It's 
> something to be considered in this context.
>
> Seth
>
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090606/a0373089/attachment.html