Policy RFC: branches/2.0 change process

Derek Atkins warlord at MIT.EDU
Wed Jul 12 14:54:04 EDT 2006


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 wish there were some way to mark a bug with states "commited to
trunk, awaiting approval, and approval granted"

       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

More information about the gnucash-devel mailing list