My vote is #2.
I would like to see a REVIEWERS file, and a general statement
that if you are going to make big changes you should discuss
it on -dev/IRC and/or with the REVIEWERS listed for that module
and that backing out a checkin only requires an even vote (that
is if you get a bad review you need to find someone else to
support you or back it out till you can satisfy the reviewer...
ties go to that status quo).
john
On 2/26/2010 4:46 PM, Leif Hedstrom wrote:
> Quick update:
>
> It's been brought to my attention that CTR is basically the equivalent
> to no-review. So, simplifying even further, there are only two types of
> reviews, RTC and CTR.
>
> CTR would mean that commits can be voted out, a CTR commit is the
> equivalent of a request for a lazy consensus vote.
>
> -- leif
>
> Here are the four policies I'd like to propose, and which we'll vote on
> later (don't vote yet please!):
>
> 1. RTC for everything except trivial changes (e.g. comments etc.).
> This has effectively been the policy so far.
> 2. CTR for trunk, RTC for all release ("stable") branches.
> 3. A more relaxed policy, with RTC for all release branches, and RTC
> for trunk, except
> * Small code changes (few lines of code, comments etc.) - CTR
> * Everything else - RTC
> 4. Like #3, but even more relaxed, release branches are still RTC:,
> and RTS for trunk, except
> * Small code changes that would take no longer than 5 minutes
> to review - CTR
> * Everything else - RTC
>
>
>
