Policy RFC: branches/2.0 change process

[Josh Sled]

On Wed, 2006-07-12 at 14:54 -0400, Derek Atkins wrote:
> 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.

I don't think we need this for every commit, necessarily, so much as
agreement to exercise restraint w.r.t. the branch, and to call for a
review if a particular change warrants it.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060712/47ad2098/attachment.bin