[WG: Sakai QA] Sakai 2.6.1 maintenance release recommendations

Anthony Whyte arwhyte at umich.edu
Mon Sep 14 10:54:59 PDT 2009


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090914/e1c51b04/attachment.bin 


More information about the sakai-qa mailing list