[OPEN-ILS-DEV] Managing RC bug merges
Galen Charlton
gmc at esilibrary.com
Wed Sep 5 10:22:55 EDT 2012
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.
> 2. I'd like to change the definition of "showstopper", i.e. what can
> and cannot make it into an RC. I propose that any reasonable bug fix
> may be merged into an RC provided the commit has 3 sign-offs in total
> -- the author, plus 2 additional testers. That would allow us to
> avoid the whole
> benevolent-overlords-blessing-problems-as-showstoppers process, which
> is vague and time-consuming, while maintaining a generally higher
> level of quality for any fixes merged into the RC.
>
> In other words, let the market decide. If a problem merits attention
> (and showstoppers will), then it will be merged. If it's not a
> showstopper in the traditional sense, but really improves things, it
> can get merged too.
+1
Regards,
Galen
--
Galen Charlton
Director of Support and Implementation
Equinox Software, Inc. / The Open Source Experts
email: gmc at esilibrary.com
direct: +1 770-709-5581
cell: +1 404-984-4366
skype: gmcharlt
web: http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
More information about the Open-ils-dev
mailing list