Policy RFC: branches/2.0 change process

[Chris Shoemaker]

On Wed, Jul 12, 2006 at 02:54:04PM -0400, Derek Atkins wrote:
> Hi,
> 
> I'd like to propose a change process for making changes to the 2.0
> release branch.  The goal of this proposal is to limit the number of
> potential bugs that enter the 2.0 branch due to changes made to the
> sources.  Considering we're going to try to get a 2.1 series in the
> fall and 2.2 by the end of the year, I expect only three or four 2.0.x
> releases, so I'd like to limit the potential for a "bad release".
> 
> I think my proposal is pretty simple:
> 
> 1) Translation changes can be committed directly to branches/2.0 I
>    think we're in agreement that there's no harm in updating
>    translations, and the 2.0 release branch is meant for translations.
>    No other part of this proposal apply to translation updates.
> 
> 2) Any other changes must first be committed to trunk and then
>    vetted/audited by at least one other developer before the changeset
>    is "allowed" to be merged into branches/2.0.  In other words,
>    developers should not commit code to the 2.0 release branch before
>    another developer has "approved" the change.
> 
> 3) Requests for "approval" can be made either here on -devel or
>    on IRC, although here on -devel is "preferred".
> 
> 4) All changes requested for backport to branches/2.0 must have an
>    associated bugzilla bug#
> 
> So, that's my proposal.  What do y'all think?

I think we can just agree that /trunk is for development and
/branches/2.0 is for bugfixes only.

Also, I would rather not commit changes eventually destined for
/branches/2.0 to trunk first and then merge individual changesets to
the branch.  That will become increasingly fuzzy as trunk diverges.

Instead, if the fixes are made on /branches/2.0, then the branch can
be repeatedly pulled into trunk.  Essentially, /trunk is constantly
being rebased off the tip of /branches/2.0.  This won't suffer any
divergence, because all previous changes to /branches/2.0 will already
be in /trunk.

I don't see any need to "backport" changesets at all.

-chris

> 
> I wish there were some way to mark a bug with states "commited to
> trunk, awaiting approval, and approval granted"
> 
> -derek
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel