[OPEN-ILS-DEV] Managing RC bug merges

[Bill Erickson]

On Wed, Sep 05, 2012 at 10:22:55AM -0400, Galen Charlton wrote:
> Hi,
> 
> On 09/05/2012 09:27 AM, Bill Erickson wrote:
> >1.  Create an origin/rel_2_3_rc1 branch.  (I mentioned this briefly
> >in my recent RC1 planning email).  It will be a child of
> >tags/rel_2_3_rc1.  All fixes that meet the RC standards (more below)
> >may be merged into this branch.  tags/rel_2_3_0, and subsequently the
> >2.3.0 release, will be derived from the origin/rel_2_3_rc1 branch.
> >
> >Regular fixes will merge into master -> rel_2_3.  RC fixes will merge
> >into master -> rel_2_3 -> rel_2_3_rc1.
> >
> >This adds an additional step to getting code into the RC / final
> >release, but I think that's better than temporarily complicating the
> >standard bug-merging work flow.
> 
> As per our current discussion in #evergreen, at the moment I prefer
> that we designate a fixed period of time for the triple-signoff
> requirement, and I further suggest that during this period that
> nothing gets merged into rel_2_3 that folks aren't comfortable
> having in the 2.3.0 release.  If we need a separate branch -- and
> I'm not sure that we do -- I counter-propose that we define a
> rel_2_3_pending_bugfixes branch for rel_2_3 bugfixes that we're not
> presently comfortable including in the 2.3.0 release.

It occurred to me during this discussion that my sense of the purpose of the major release RC is too rigid.  Otherwise, I would not have suggested the triple-sign-off.  My goal was to apply a special level of care for the X.Y.0 release.  But, in retrospect, why?  As it stands, we don't apply any special barriers to bug fixes which are merged into other X.Y.Z releases (2.2.3, 2.3.1, etc.).  Unless we are planning to have an across-the-board 3pl-sign-off period before every X.Y.Z release (which effectively puts us into perpetual 3pl-sign-off mode), why should X.Y.0 be any different?  I think the the two-sign-off process we have in place works quite well (and it's clearly sufficient for other releases).  I have now come full circle (apologies for muddying the waters) to thinking we just stick w/ the standing 2-sign-off and allow bug fixes to continue flowing into rel_2_3 the same as they would prior to any 2.3.X release.

Surely there's a psychological difference between 2.2.3 and 2.3.0, but I don't see one in practice.  If anything, 2.2.3 has *more* cause to be handled with kid gloves, since 2.2 is much more widely used in production systems.

Am I talking crazy here?

-b 

-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com 
| Equinox Software, Inc. / Your Library's Guide to Open Source