[WG: Sakai QA] 2.6.1: in/out

Wed Sep 30 07:36:11 PDT 2009

Hello,

What you see below is a current thread that needs to go public. 
It started out as a status update request, but has lot of useful 
information about the proposed forthcoming 2.6.1 release.

To Pete's response below, I thought a small group was 
discussing/forming recommendations for changes to improve our use 
of Jira. This was discussed in Boston. Has anything bee put into 
writing?

Seth

Pete Peterson wrote:

> I agree with most of this, but I think the "Fix Version", 
> should represent the "Fixed Version". In other words I think it 
> should be limited to only released versions. If this field is 
> used as a place holder for tentative releases, then we have the 
> potential for possibly excluding these fixes. For example a fix 
> is marked "Fix Version 2.6.2", but doesn't get merged into the 
> branch in time. We then need to go and manually find these 
> stragglers and change them all to 2.6.3. It makes much more 
> sense to me to have this field blank until it the issue is 
> released in a version. I don't think it should be used as a 
> target version field.
> 
> Thoughts?
> 
> Pete
> 
> From: Anthony Whyte [mailto:arwhyte at umich.edu]
> Sent: Tuesday, September 29, 2009 5:27 PM
> To: Noah Botimer; Kirschner Beth; Qian Zhen; Jones Matthew; Jean-Francois Leveque; May Megan; Li Lydia; Karen Tsao
> Cc: Theriault Seth; Horwitz David; Pete Peterson; sakai-foundation-staff sakai-foundation-staff
> Subject: 2.6.1: in/out
> 
> Please take a moment to review the closed issues that Jira tells me are ready for merging to 2.6.x with an eye on what you deem is essential to include in 2.6.1.  There is a healthy set of assignment fixes to review, another set of French translations, a chunk of gradebook fixes and other stuff.  There may well be other needed fixes that the 2.6 filters aren't picking up -- is so please update Jira.
> 
> 2.6.x merge candidates
> http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12075
> 
> 2.6 resolved issues (critical)
> http://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=12101
> 
> Also I want to propose that we cease using any maintenance branch for a fix version and instead select actual and tentative versions (plus trunk) only.  I reviewed and fixed hundreds of Jiras today by comparing svn commits against fix versions in order to try and achieve an accurate 2.6.1 list of fixes.  In my view,  2.6.x as an affects version is ok but we should limit the fix version to actual versions, whether released or not (look ahead fix versions are good).
> 
> So if you merge an issue to 2.6.x before we release 2.6.1, set the fix version to 2.6.1 and get rid of any fix version reference to 2.6.x.  Unless, of course, you disagree.  If you do let's talk about this now because I want to send an email out on tomorrow on this aspect of Sakai Jira practice.
> 
> By the way, I am not suggesting you merge anything more into 2.6.x; but if something is outside of 2.6.x that needs to be in so that it gets picked up by 2.6.1 please merge it (and or discuss it on list).
> 
> Cheers,
> 
> Anth
> 
> 
> Begin forwarded message:
> 
> 
> From: Anthony Whyte <arwhyte at umich.edu<mailto:arwhyte at umich.edu>>lyd
> Date: September 29, 2009 7:44:21 PM EDT
> To: Sakai QA <sakai-qa at collab.sakaiproject.org<mailto:sakai-qa at collab.sakaiproject.org>>
> Cc: "sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org> Developers" <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>>
> Subject: 2.6.1 update
> 
> 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<mailto:arwhyte at umich.edu>>
> Date: September 14, 2009 1:54:59 PM EDT
> To: Developers Sakai <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>>, Sakai QA <sakai-qa at collab.sakaiproject.org<mailto: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
> 
> 
> 