[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