[WG: Sakai QA] 2.6.1 update

Anthony Whyte arwhyte at umich.edu
Tue Sep 29 16:44:21 PDT 2009


I spent a good deal of time today cleaning up Jira in order to provide  
an overview of the upcoming 2.6.1 release.  I've cleared away a large  
number of issues (200+) not properly associated with the 2.6.0 release  
which have made it difficult to track post-2.6.0 fixes destined for  
2.6.1.   My view of the issues as of tonight is listed below:

Jira highlights (current)

2.6.1 fixes = 100
2.6.x/2.6.1 merge candidates = 58
2.6.1 blockers = true
2.6.1 conversion scripts required = true

2.6.1 is heavy on I18n (internationalization) updates and fixes to  
assignments and portfolios.  Further details respecting the release  
can be gleaned from the reference section below.


REVIEW 2.6 ISSUES

Project teams should review issues lodged against their 2.6 code.  If  
fixes you deem are essential for the health and well-being of 2.6.1  
have yet to be merged to the 2.6.x maintenance branch, please alert  
the release/branch management team (listed in Confluence).

http://confluence.sakaiproject.org/display/REL/Release+Management+Team


RELEASE WEEK

My plan is to create a 2.6.0 release branch (a copy of 2.6.x) no later  
than Friday, 2 October 2009 in order to perform pom tweeks and  
generate artifacts for a release during the week of 4-9 October 2009.

Unlike previous "rationed" maintenance releases that mapped to a  
variable set of maintenance branch project revisions, 2.6.1 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.

In order to hit these dates the following issues must be resolved:

1. elimination of blockers and regressions
2. creation of 2.6.0->2.6.1 conversion scripts
3. final resolution of  2.6.x/2.6.1 merge candidates.  Those deemed  
essential for this release by the branch management team get merged,  
the rest get bumped to 2.6.2 and beyond.

Once the above conditions are satisfied the following will occur:

1. release branch is created based on the chosen *.x branch revision;  
branch poms are tweeked as necessary
2. release branch is deployed to QA servers for final QA review
3. release artifacts are generated, 2.6 release notes are updated and  
code is publicly released (ideally within 3-4 business days of initial  
branching in order to limit artifact staleness)
4. we start work on 2.6.2 for a mid-November release.

cheers,

Anthony

_________________________________

REFERENCES

2.6.1 FIXES (MERGED TO 2.6.x)

2.6.1 fixes (n=100) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12092

The Jira 2.6.1 version filter (http://jira.sakaiproject.org/browse/SAK/fixforversion/11484 
) inflates the number of issues currently merged to 2.6.x  and  
destined for 2.6.1 as it filters on version and resolution (fixed) but  
see also:
2.6.1 issues n=127 (this number includes closed as well as resolved  
fixes that have yet to be merged to 2.6.x branch) http://jira.sakaiproject.org/browse/SAK/fixforversion/11484 
; see merge candidates below.
2.6.1 issues (unresolved) n=20 http://jira.sakaiproject.org/secure/BrowseVersion.jspa?id=10010&versionId=11484&showOpenIssuesOnly=true


2.6 MERGE CANDIDATES

These issues are fixed, closed and ready for merging to 2.6.x.  Branch  
managers should review these issues as to whether or not they should  
be included in 2.6.1 or bumped to 2.6.2.

2.6 merge candidates (n=58) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12075


2.6 RESOLVED (AWAITING TESTING VERIFICATION)

Unless a compelling reason is advanced to include any of these  
resolved issues in 2.6.1, these fixes that are awaiting testing  
verification will be bumped to a future maintenance release.

2.6 resolved blockers (n=0) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12102
2.6 resolved critical (n=14) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12101
2.6 resolved other (n=176) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12100


2.6 OPEN (UNRESOLVED)

Open unresolved issues will be bumped to 2.6.2 and beyond unless there  
is a compelling reason to escalate an open 2.6 issue to blocker status.

2.6 open blockers http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12086

* A number of issues currently block me from releasing 2.6.1.    
However, I recommend that only SAK-17057 be considered a 2.6.1  
blocker.  The others, all unassigned, should be bumped to 2.6.2.  If  
you disagree with this assessment please email me with reasons.

http://jira.sakaiproject.org/browse/SAK-17057

2.6 open critical (n=69) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12087
2.6 open other (n=933) http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12060


KNOWN CONVERSION SCRIPT ISSUES

http://jira.sakaiproject.org/browse/SAK-16809
http://jira.sakaiproject.org/browse/SAK-16548
http://jira.sakaiproject.org/browse/SAK-16847


KNOWN PROPERTIES ISSUES (changes, additions, missed)

asn.share.drafts  http://jira.sakaiproject.org/browse/SAK-16753


RELEASE NOTES ADDITIONS

Update documetation re: time outwarning properties per
http://www.nabble.com/-Building-Sakai--Time-out-warning-td25599130.html



Begin forwarded message:

> From: Anthony Whyte <arwhyte at umich.edu>
> Date: September 14, 2009 1:54:59 PM EDT
> To: Developers Sakai <sakai-dev at collab.sakaiproject.org>, Sakai QA <sakai-qa at collab.sakaiproject.org 
> >
> Subject: Sakai 2.6.1 maintenance release recommendations
>
> 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 --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090929/1b051135/attachment-0001.html 
-------------- 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/20090929/1b051135/attachment-0001.bin 


More information about the sakai-qa mailing list