[VOTE] Commit Policy on 2.2.x

[Paul Querna <ch...@force-elite.com>]

I propose the following policy apply to the 2.2.x branch, once (and if)
it is created:

Before GA: A 'soft' CTR.  Any small bug fixes can be directly committed.
  Any API changes must be reviewed by the list. (lazy consensus).  Any
large changes must get voted on.

After first GA: Standard RTC, as done on 2.0.x.

Re: [VOTE] Commit Policy on 2.2.x

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Wednesday, May 11, 2005 6:49 PM -0700 Paul Querna <ch...@force-elite.com> 
wrote:

> I propose the following policy apply to the 2.2.x branch, once (and if)
> it is created:
>
> Before GA: A 'soft' CTR.  Any small bug fixes can be directly committed.
>   Any API changes must be reviewed by the list. (lazy consensus).  Any
> large changes must get voted on.

Per my previous email that I sent to the list a while back, I would prefer 
that a stabilization branch require that binary API changes get prior approval 
through RTC (i.e. *not* lazy consensus).  Any changes that are committed to 
the trunk during this process that do not modify the binary API can be 
committed via lazy consensus (i.e. CTR).

The governing factor is changes to the API must be voted on before it can be 
merged into the stabilization branch.

> After first GA: Standard RTC, as done on 2.0.x.

+1.  -- justin

Re: [VOTE] Commit Policy on 2.2.x

[André Malo <nd...@perlig.de>]

* Paul Querna wrote:

> I propose the following policy apply to the 2.2.x branch, once (and if)
> it is created:
>
> Before GA: A 'soft' CTR.  Any small bug fixes can be directly committed.
>   Any API changes must be reviewed by the list. (lazy consensus).  Any
> large changes must get voted on.

According to my other mail, I'm going to apply your suggestion to a 2.1.x 
branch:

I see a problem with it in general: Who decides if it is a small bugfix or 
something bigger? Since our test suite is far from being complete and the 
code is full of side effects *I* would not like to be the one to decide 
such things ;-)

I tend to vote -1 on CTR in whatever flavor on stable and stabilizing 
branches (except documentation, comments and text-only changes, FWIW).

nd
-- 
Winnetous Erbe: <http://pub.perlig.de/books.html#apache2>