[sakai2-tcc] Proposal: trunk is 2.9 from Sept-Jan until sakai-2.9.0-rc01 is ready for tagging

[Berg, Alan]

+1


Alan Berg

Group Education and Research Services
Central Computer Services
University of Amsterdam

________________________________________
From: sakai2-tcc-bounces at collab.sakaiproject.org [sakai2-tcc-bounces at collab.sakaiproject.org] on behalf of Steve Swinsburg [steve.swinsburg at gmail.com]
Sent: 17 September 2011 02:52
To: Anthony Whyte
Cc: sakai2-tcc Committee; Developers Sakai-Dev
Subject: Re: [sakai2-tcc] Proposal: trunk is 2.9 from Sept-Jan until    sakai-2.9.0-rc01 is ready for tagging

I like this approach, +1

Sent from my iPhone

On 17/09/2011, at 8:01, Anthony Whyte <arwhyte at umich.edu> wrote:

> I'd like to propose a change in how we manage CLE trunk and our maintenance branches as we approach the sakai-2.9.0 code freeze date of 20 Sept 2011.
>
> Current practice involves creating a series of *.x maintenance branches on 20 September and allowing trunk to immediately commence its evolution towards the next release (e.g., sakai-2.10.0).  It's convenient for new development work but requires that branch managers expend considerable energy both reviewing tickets and merging code to *.x branches in order to ensure that bug fixes intended for 2.9 are included in the next QA tag.
>
> I propose that we reconsider this tradition and instead adopt the following approach:
>
> Non-indie trunk branches remain 2.9-SNAPSHOT until we are ready to tag the first release candidate.  New work not intended for 2.9.0 is performed in branches and held there until we branch trunk for 2.9.  Indie projects also adopt the same approach; trunk stays 2.9-oriented while new work is performed in branches.  The release team cuts alpha/beta QA tags from trunk.
>
> I see the benefits as three-fold.
>
> 1.  Developers concentrate on stabilizing trunk between the months of Oct-Dec.  The focus is on bug fixing.
>
> 2.  Branch management work between Sept and the final beta candidate is effectively eliminated and branch managers (all of whom are developers) can assist in stabilizing trunk.  The drudgery index associated with this type of work falls as a result.
>
> 3.  CLE developers work together to monitor trunk commits (only a few do this currently).   Questionable commits are discussed on list and if necessary reverted.  Someone pushing new work into trunk before the first 2.9 release candidate would receive a polite scolding and their work is redirected to a branch.  A renewed or expanded interest in trunk commits is in the interest of all.
>
> If this is going to work  CLE developers need to agree to push new work to branches.  Second, they need to be willing to monitor commits and speak up if a commit appears questionable to them.  Git makes gate-keeping easier but the CLE developer team is not large, its membes know each other well and are capable of operating in a disciplined manner.
>
> One potential gotcha is that indie QA tags using the release plugin need to ensure that the working branch (trunk) is not incremented when a release is performed (e.g., basiclti-1.4-SNAPSHOT is not incremented to 1.4.0-*, 1.4.1-* etc).  This is easy enough to accomplish during a release but requires manual intervention; ideally we would script this across the set of indies.
>
> Anyways, an idea to consider as we approach the freeze.
>
> Cheers,
>
> Anthony
>
>
>
>
>
>
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
_______________________________________________
sakai2-tcc mailing list
sakai2-tcc at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc