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

[Matthew Jones]

I also like this approach. (+1) All of the release team and branch team is
developers so it seemed to be either a decision between devoting time to
fixing bugs (and keeping out new features) or merging fixes (and having less
time to fix bugs).

I also know people might be scrambling to get last minute changes in before
Tuesday and now, like in the past, freeze has typically just meant "freeze
from new major unfinished features". Small previous finished or nearly
finished features, bug fixes found during testing and security fixes will
most certainly get in during this alpha/beta phase. We'll just watching for
commits (in step 3 mentioned by Anthony) that change a ton of files or look
like they're adding something substantial.

On Fri, Sep 16, 2011 at 8:52 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> 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
> _______________________________________________
> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110917/f92b936d/attachment.html