[WG: Sakai QA] [Building Sakai] Sakai 2.6.1 maintenance release recommendations

[David Haines]

These look like very good changes to speed up the process.

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu




On Sep 14, 2009, at 1:54 PM, Anthony Whyte wrote:

> 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
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"