[WG: Sakai QA] [Management] Release proposal revisited

[Pete Peterson]

Greetings,

Responses/comments in-line below.

> -----Original Message-----
> From: management-bounces at collab.sakaiproject.org [mailto:management-
> bounces at collab.sakaiproject.org] On Behalf Of Clay Fenlason
> Sent: Tuesday, September 01, 2009 8:12 AM
> To: management at collab.sakaiproject.org; Sakai QA; sakai-
> dev at collab.sakaiproject.org Developers
> Subject: Re: [Management] [WG: Sakai QA] Release proposal revisited
> 
> Some responses in-line below.  A caveat about the language: 'tool
> release' is a fair way to get started thinking about it, but we might
> generalize that to 'module release.' I'll keep talking about tools for
> now, though, since I think that makes it easier to digest:
> 
> On Tue, Sep 1, 2009 at 9:40 AM, Jean-Francois
> Leveque<jean-francois.leveque at upmc.fr> wrote:
> > If Forums is released with new features after 2.6 and before 2.7, how
> is
> > this Forums release gonna be tagged?
> 
> If I'm understanding the question, I think the tool version numbering
> needs to be entirely de-coupled from Sakai versions. Part of the point
> would be to allow tools to make their own decisions about major and
> minor releases, frequency of releases, etc. Fitting themselves beneath
> an overarching numbering system would just get in the way.  So I think
> this should be left to the respective team.
> 
> The cost of this, of course, is the care that would have to go toward
> getting the right versions into a particular general Sakai release
> cycle, especially where there may be cross-tool dependencies. Still,
> that seems manageable. Tool release teams will also likely want to
> provide documentation on which versions they have been tested against
> and which they should be good for, given known API changes.

A suggestion that has some merit; the numbering could/should reflect the maturity of the Module (BTW +1 to "module" moniker); e.g., Modules that have been in Sakai core releases for several years might start their release numbering at 2.x.x or 3.x.x, while relatively new tools could be 1.x.x or 0.x.x. 

> > Are we doing independent tools releases and building Sakai releases
> with
> > kernel, API layer and chosen tool releases?
> 
> I'm not certain of the answer you're looking for here, but I think
> you've described the general idea. Let me run through a couple points
> with a little more precision, though. An independent tool release will
> not be published by the Sakai Foundation in the way that general Sakai
> releases are now, at least not yet. I'm thinking of them more like the
> mature contrib tool releases (think of Nuno's recent release of
> SiteStats 2.0). The main claim of an independent release is that it is
> *internally* complete, consistent, and release-worthy as checked
> against a known stable branch of Sakai code (i.e. a certain K1
> version, etc.). Whether it introduces regressions in other components
> (and vice-versa) will be a matter for general release QA, though
> documenting a tool release should include a discussion of API changes,
> known dependencies and associated implications. The big difference for
> the general QA cycle is that documented, tested, and functionally
> complete tags of certain modules will be taken as inputs rather than
> the latest trunk at a code freeze date.
> 
> That's another way to think about this: as independent module releases
> become more common, we're progressively shifting away from a global
> code freeze of trunk, and letting modules iterate on their own
> timeframes.  There will not be so much a big freeze date as a big
> 'bundle date,' if you will.  That is to say, at some point in time,
> the pieces that are ready to go are tied together and tested as a unit
> for a general Sakai release.  If you're not ready with a new version
> for a new Sakai release, no worries, they can run with the old one,
> and you can keep working on your tool releases for next time (or for
> deployers that are prepared to pull it in after the fact).
> 
> > How easy will it be to upgrade a Sakai release only for chosen tools
> > (use later tool releases than the one in the official Sakai release)?
> 
> This will depend in large degree, of course, on the tool itself and
> the scope of change in a given tool release.  As mentioned above, the
> tool release should document API changes, which other components it's
> been tested against, what versions of Sakai it should work with, any
> DDL scripts, etc.

I like the terminology "bundle date" replacing freeze date. Clay's point, "Whether it introduces regressions in other components (and vice-versa) will be a matter for general release QA...", is a good one. Full QA regression testing will be tied to a general release schedule. It is likely that we would evaluate these module releases early on in preparation of the full release.  An added benefit would be that some institutions maybe running these new modules in production which would provide invaluable QA testing and refinements to the module as well. I also believe this style of deployment would reduce or eliminate regressions in Sakai releases and improve the overall stability and confidence in the release. 

> > Is 2.6 ready for this?
> 
> At this stage I don't think any tools are going to try to start this
> against a 2.6.x foundation.  But again, there's nothing stopping a
> given team from doing so, it's just a question of the responsibility
> they're prepared to take on.  By the same token, not all tools will be
> taking on this responsibility during the next big release cycle. We'll
> start with those that could most benefit from it, and which are ready
> to manage themselves in this way.  If it goes well, the practice may
> be extended.

I find this one of the big benefits of this process proposal. A module development team can write a module release, if they have the motivation to do so, for maintenance versions of Sakai as well as the next full release version and those institutions with the expertise to do so, could install the new tool in these maintenance versions prior to the next general release. 

> 
> > Will 2.7 be ready for this?
> 
> Again, the question is not so much if 2.7 is ready for this, it's
> whether a given module/project leadership is ready for it.  We have
> started some conversations with coordinated teams that might take on
> this approach before and during the big 2.7 cycle, yes.  Right now I'm
> trying to see if release teams can't be coordinated around
> Forums+Messages (since those two share a single module), I think the
> Samigo team is thinking about it, and perhaps Site Info as well. I'd
> also encourage this for tools that are not part of the core code in
> 2.6 but would like to be considered for a future Sakai release: if you
> get into the habit of putting out documented, tested releases you'll
> be in a good position for community uptake, whether within a Sakai
> release or deployed as an extra.
> 
> At the same time, Pete Peterson is mapping out a QA plan which
> incorporates the idea of progressively including tool releases rather
> than a single, global code freeze. Anthony Whyte is also working
> through the details on the release management side of things, and I
> expect we'll have documentation on how a team could manage its affairs
> in this way, as far as svn and maven are concerned.  We're talking
> about all these things at the weekly release planning meetings as
> well.

As stated before we would be reviewing and evaluating these modules for the next full release of Sakai. We hope this methodology will allows us to focus and leverage our QA resources more effectively. 

> 
> ~Clay
> 
> PS I'm going to post up some other notes that have been raised in
> discussion on this, and try to have a FAQ available in Confluence.  On
> my to-do list for the week.
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
> 
> TO UNSUBSCRIBE: send email to management-
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"