[sakai2-tcc] Update: Sakai CLE 2.8.0 Community Release

[Anthony Whyte]

15 February 2011 is the date when the TCC is scheduled to review the readiness of the 2.8.x branch for release as sakai-2.8.0.  I want to provide you with a quick briefing of where we are at today in order to better inform our decision regarding readiness to release.


RC WHEN? (https://confluence.sakaiproject.org/display/REL/Sakai+2.8+Release+Schedule)

The first release candidate was scheduled for tagging on 11 Jan 2011.  Instead, I issued sakai-2.8.0-b03 (beta) instead of an RC.  I did so for the following reasons:

1) unresolved blockers (including conversion script testing)
2) large numbers of fixes flagged for merging (suggesting code instability)
3) a lack of functionality testing compounded by an unclear understanding of what has/has not been tested

The next QA tag is schedule for 25 Jan 2011.  The conditions above have hardly changed although I should note that the first in a series of promising Functionality Test Fest events took place last week (see https://confluence.sakaiproject.org/display/QA/2.8+Test+Fest).  Nevertheless, blockers still exist, merge requests have yet to stabilize, conversion scripts remain untested, while functionality testing is only just commencing.

Given the above, I plan to issue another beta tag rather than a release candidate on Tue/Wed this week (sakai-2.8.0-b04).  As a result we will be off-schedule by some four weeks when I issue the next tag on 8 February 2011.


BLOCKERS (https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12708)

Given the tag slippage described above the release candidate phase of the schedule will need to be compressed in order to produce a Community 2.8.0 release by 1 March 2011.  This raises questions regarding our tolerance for risk; however, I recommend that we focus on the existing set of blockers and decide which ones, if any, either introduce embarrassing regressions or imperil the release from a performance or security point of view. 

I do not accept the status of Jira tickets uncritically.  One person's blocker is another person's critical ticket (the converse is also true).  Last week during the RM call Beth Kirschner, Megan May, Alan Berg, Jean-Francois Leveque and myself triaged the blocker list and downgraded the priority of a half dozen tickets.  I followed up this work with individuals emails to blocker assignees (not all have replied).  There is nothing new in this approach--we've been triaging tickets since 2.5 if not earlier.

Not all blockers currently listed need to hold up the 2.8.0 release in my opinion.  I will not go into further detail on this list regarding individual tickets but I encourage you to review the current blocker list and send me your opinions.

If the current set of blockers are not true blockers, we should downgrade their status and prep for release; otherwise, we should continue to issue QA tags every other week until all blockers are eliminated. 


RUTGERS TIMELINE (OUR TIMELINE?)

Rutgers intends to deploy 2.8.0 in production in May 2011 with local testing planned for February and March.  I know of no other organizations planning a rollout of 2.8.0 during Q1/Q2 2011 but ignorance such as this is due to the fact that no one (including myself) has polled the Community on the question.   

We probably have two choices here: 

1.  we adhere to the existing schedule, eliminating all true blockers in the next two weeks and then issuing sakai-2.8.0-rc01 for Rutger's use on 8 Feb 2011.  As with previous releases, sakai-2.8.0-rc01 will be tagged from a release branch in order to allow non-blocker fixes to flow to 2.8.x.  We then prep for release during  21-25 February and release sakai-2.8.0 on 1 March 2011.  However, this leaves us little or no room to respond to any blocker/critical issues that Rutgers (or the Marist/rSmart Test Fest) may discover during the month of February.  Such an approach could well doom us to an early 2.8.1 maintenance release--involving additional work not merely for the release team but also deployers.

2.  we modify the current schedule to better incorporate Rutgers and Test Fest testing.  Again, we endeavor to eliminate all true blockers in the next two weeks, issuing sakai-2.8.0-rc01 on 8 Feb 2011.  Two weeks later on 22 February we issue sakai-2.8.0-rc02; if necessary we issue another RC tag on 8 March 2011.  We prep for release on 21-25 March 2011 and release the following week by 31 March 2011.  This latter approach provides us with an opportunity to produce a couple of RC tags that includes fixes produced in response to Rutgers and Test Fest testing.

I prefer option 2 as I believe it is better aligned to current realities including better hooks into Rutgers and Test Fest QA activities than option 1.

What say you?

Cheers,

Anthony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110124/61bf4ef9/attachment.bin