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
