[cle-release-team] Proposal: towards a releasable trunk for Sakai 10 (and beyond)

[Adrian Fish]

Hi Anth,

How do we decide what the v10 capabilities are? In other words how do we
find out what we can/should be working on up to the branch date?

Cheers,
Adrian.


On 14 November 2013 15:00, Anthony Whyte <arwhyte at umich.edu> wrote:

> *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
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20131114/c50baa5d/attachment-0001.html