[Building Sakai] Sakai 2.6.1 maintenance release recommendations
David Haines
dlhaines at umich.edu
Thu Sep 24 06:33:04 PDT 2009
These look like very good changes to speed up the process.
- Dave
David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu
On Sep 14, 2009, at 1:54 PM, Anthony Whyte wrote:
> 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
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
More information about the sakai-dev
mailing list