Policy RFC: branches/2.0 change process

[Chris Shoemaker]

On Wed, Jul 12, 2006 at 07:33:55PM -0400, Derek Atkins wrote:
> Quoting Chris Shoemaker <c.shoemaker at cox.net>:
> >I don't see any need to "backport" changesets at all.
> 
> Then how do we get a proposed change audited before it's commited to
> the 2.0 branch?

FTR, my counter-proposal is:

We commit bugfixes to the 2.0 branch, where they'll actually be in the
context that we intend to release them it.  Then, we anoint a 2.0
gatekeeper (Derek) who is responsible for reverting any change on the
branch that hasn't been reviewed by another dev within N days. (I
propose N = 7.)

BTW, I can quite easily imagine me needing to fix bugs in code that
I've deleted from /trunk.  I don't see any way to review them other
than in the branch context.

I've certainly seen setups where no code was supposed to be commited
before being reviewed, so your proposal has precedent.  I just want to
keep the (hopefully) common case (reviewed code is correct) as cheap
as possible.

-chris