Policy RFC: branches/2.0 change process
Derek Atkins
warlord at MIT.EDU
Wed Jul 12 14:54:04 EDT 2006
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 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
More information about the gnucash-devel
mailing list