[WG: Sakai QA] Sakai 2.6.1 maintenance release recommendations
Jean-Francois Leveque
jean-francois.leveque at upmc.fr
Tue Sep 15 01:42:32 PDT 2009
+1
So the changes that need database changes will be dealt with updated
conversion scripts.
Do we already have something set up for automated testing of
sakai-2.6.x-qa, sakai-2.6.x and 2.6.1, Pete?
I haven't been able to attend the RM meetings. Is there documentation
about the review process? Will there be a RM meeting next Thursday ?
Cheers,
Jean-François
Anthony Whyte a écrit :
> 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
More information about the sakai-qa
mailing list