[WG: Sakai QA] Sakai 2.6.1 maintenance release recommendations

Jean-Francois Leveque jean-francois.leveque at upmc.fr
Tue Sep 15 01:42:32 PDT 2009


+1

So the changes that need database changes will be dealt with updated 
conversion scripts.

Do we already have something set up for automated testing of 
sakai-2.6.x-qa, sakai-2.6.x and 2.6.1, Pete?

I haven't been able to attend the RM meetings. Is there documentation 
about the review process? Will there be a RM meeting next Thursday ?

Cheers,

Jean-François

Anthony Whyte a écrit :
> The 2.6.x maintenance branch is overripe for a maintenance release:  the 
> merge delta between 2.6.0 and 2.6.x now stands around 260, roughly half 
> the 2.6.x merges involve fixes to code while the remainder involve 
> updates to internationalization property bundles.  In particular, 2.6.x  
> assignment, chat, portfolio and site-manage have witnessed a good deal 
> of merge (e.g., bug fixing) activity.  In addition, new updates for 
> Catalan, French, Russian, Spanish and Swedish translations have been added.
> 
> Sitting outside the 2.6.x branch are an additional 120 fixed issues with 
> an affects version of 2.6.* that should be reviewed for potential 
> inclusion in 2.6.1:
> 
> 1. 45 fixed issues that are closed with a request to merge to 2.6.x.  
> Assuming these are tested, this set should be reviewed by RM/QA/project 
> teams for inclusion in 2.6.1, and if appropriate, merged.
> 2. 75 fixed and resolved issues with a request to merge to 2.6.x.  These 
> require testing verification before merging can take place.   They too 
> should be reviewed for inclusion in 2.6.1 or pushed to 2.6.2.
> 
> I recommend we cut the 2.6.1 release on Monday, 28 Sept 2009 with a 
> followup 2.6.2 release to occur sometime before Thanksgiving.  Sometime 
> between 16-18 September I would create a 2.6.1 release branch based on a 
> known revision of 2.6.x (rXXXXX).  Unlike previous "rationed" 
> maintenance releases that mapped to a variable set of maintenance branch 
> project revisions, 2.6.1 and future maintenance releases will take the 
> entire maintenance branch at a known point in its revision history.  The 
> release will then be cut from this parallel branch within a few days of 
> branching in order to limit the artifact "staleness" that characterizes 
> current Sakai maintenance releases when compared to their parent *.x 
> branch.
> 
> No freezing of the 2.6.x maintenance branch will be required.  No alpha, 
> beta, or rc tags will be generated prior to the release.  Instead, a new 
> sakai-2.6.x-qa branch 
> (https://source.sakaiproject.org/svn/sakai/branches/sakai-2.6.x-qa/) has 
> been created to facilitate pre-release testing.  This branch is updated 
> periodically (e.g., weekly) based on a known 2.6.x revision.  The branch 
> can then be checked out and deployed to a set of *.x branch QA servers, 
> permitting QA to test changes to the branch on a near continuous basis.  
> QA testing of the "parallel" release branch would be discretionary and 
> likely limited to those tools/services that have seen a good deal of 
> merge activity (e.g., assignments, site-manage) as well as ensuring that 
> required conversion scripts are in order.
> 
> In effect, I propose the following steps when the Sakai Community 
> determines a maintenance branch is ripe for a maintenance release:
> 
> 1. Release/Branch Management/QA teams with input from project teams 
> choose an *.x branch revision point that contains no blockers, 
> agreed-upon kernel (K1) and other project bindings and a revised set of 
> conversion scripts (if the latter are required)
> 2. release branch is created based on the chosen *.x branch revision; 
> branch poms are tweeked as necessary
> 3. release branch is deployed to QA servers for final QA review
> 4. release artifacts are generated, release notes are completed, the 
> release page is updated and code is publicly released (ideally within 
> 3-4 business days of initial branching in order to limit artifact 
> staleness)
> 
> Other than QA staffing challenges, I see no impediments to cutting 
> maintenance releases both more frequently and without the long delays we 
> currently experience since *.x branch merges are (in theory) tested and 
> verified (a merge pre-req) and because  the *.x branch production branch 
> strategy adopted successfully by a number of Sakai schools suggests that 
> we should be able to operate close to the head of the maintenance branch 
> without undue risk to the health of our release artifacts.
> 
> Arguably, 2.6.1 is already a bit bloated from a fix inclusion 
> standpoint.  We should aim for smaller, more frequent maintenance 
> releases.  But if we can put out 2.6.1 in the next couple of weeks 
> followed by 2.6.2 before the year is out (a Sakai 2.5.6 release is also 
> worth exploring) we should be able to position ourselves for a release 
> early, release often strategy for 2010.
> 
> Whatever we do we should endeavor to reduce the delays that impede our 
> maintenance releases in order to help reduce the number of patches that 
> deployers are currently forced to implement when working with our often 
> stale artifacts.
> 
> Let me know what you think of these recommendations.
> 
> Anthony


More information about the sakai-qa mailing list