[WG: Sakai QA] Proposal: towards a releasable trunk for Sakai 10 (and beyond)

[Anthony Whyte]

Proposal
As a community we shift to a "releaseable trunk" mindset.   For the Sakai 10 release, we commence this mind shift by branching trunk to 10.x at the end of January 2014 rather than now, targeting ApereoCamp as the moment we freeze development and branch with a trailing string freeze date set accordingly.  Between now and then we focus development and quality assurance efforts on trunk, generating QA tags at regular intervals directly from trunk for deployment on community-provided/funded QA servers.  Contributors should focus on 10 activities; post-10 development, if any, should be held back in a working branch during this cycle.  Going forward we continue to refine our practices in order to ensure a high quality trunk capable of being released quickly and efficiently [1].

Rationale
By long tradition trunk is branched months in advance of a Sakai *.0 release.  This practice I regard as counterproductive.  Branching prematurely is costly.   It lowers our velocity as well as our agility.  We let trunk quality slip as we attempt to focus our limited quality assurance efforts on the *.x release/maintenance branch.  We burden ourselves with more work; unproductive work.  Our penchant for alpha/beta phasing also has us thinking we need to branch early (I suggest we simply issue sakai-10.0-qaX labeled tags between now, the freeze date and beyond until we've eliminated all blockers and issue the first RC).  We incur additional branch management overhead in the guise of branch managers, additional Jenkins build jobs and branch-specific QA servers long before it is truly necessary to do so.  We let trunk sink to the status of a pass through branch for fixes destined for the *.x release/maintenance branch for far too long a period of time. 

There are also timing issues to consider as regards 10 work.  There are a number of potential new capabilities under consideration for 10 that need to be prepped for inclusion, evaluated and moved to the core svn.  I doubt we can get all that done before December.

In short, I propose that we endeavor to put trunk into a releasable state first before we shift our focus to branch activities.  The trick of course is in the determination of when to branch; our ability to measure certainly requires refinement but I believe we are currently capable of moving towards a releasable trunk without adding undue risk to the project.  Moreover, if we shift our QA efforts to trunk earlier an opportunity exists to reinforce the view that Sakai QA is a vital year-round activity rather than a cyclical affair that slowly cranks itself up and down according to our long drawn out release cycles.  

Implications
Developers engaging in post-10 work will need to hold back their changes in a working branch until after trunk is branched to 10.x.  That said, developers looking beyond 10 should weigh carefully considerations of 10 throughput if new work is prioritized over bug fixes and other tasks required to prep trunk for the next release. 10 dev activities will require more on-list visibility, the trunk commit stream will require closer scrutiny and the upcoming code and string freeze dates will need to be regularly communicated.

To date, two QA servers (Longsight, UvA) have been committed to the 10 effort.  More will be needed.  Neal Caidin will coordinate the server build up as well as general QA efforts directed at trunk.


A material objection raised by a Sakai PMC member will block this proposal.  Other opinions are welcome, indeed encouraged.  Silence equals consent. 

Cheers,

Anth 

[1] As Zach Thomas has pointed out we can and should refine our trunk development techniques. See his suggested readings for an outline of new approaches that we can incorporate:  

http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/
http://martinfowler.com/bliki/FeatureToggle.html


anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20131114/76bea0cd/attachment.html