[VOTE] Switch commit policy to Commit-Then-Review

[Otto van der Schaaf <os...@apache.org>]

Hi All,

I would like to change review policy for the incubator-pagespeed-*
repositories.
Please cast your +1/0/-1 vote on the following:

Currently I think this is not explicitly defined, but we wait for at least
one peer review
before merging code, akin to RTC.
It would be good to publicly document the way our project work with regard
to this for
new and potential contributors.
I think we have two distinct commit policies to choose from [1]:

As there's going to be lots of small changes,  to keep some velocity I am
proposing
to switch to Commit-Then-Review (at least temporary).

[1] From https://www.apache.org/foundation/glossary.html

1. Commit-Then-Review
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which
permits developers to make changes at will, with the possibility of being
retroactively vetoed. C-T-R is an application of decision making through
lazy consensus. The C-T-R model is useful in rapid-prototyping
environments, but because of the lack of mandatory review it may permit
more bugs through in daily practice than the R-T-C alternative. Compare
R-T-C , and see the description of the voting process.

2. Review-Then-Commit
(Often referenced as 'RTC' or 'R-T-C'.) Commit policy which requires that
all changes receive consensus approval in order to be committed. Compare
C-T-R , and see the description of the voting process.

Otto

Re: [VOTE] Switch commit policy to Commit-Then-Review

["jmarantz@google.com" <jm...@google.com>]

+1

On 2018-01-12 16:36, Otto van der Schaaf <os...@apache.org> wrote: 
> Hi All,
> 
> I would like to change review policy for the incubator-pagespeed-*
> repositories.
> Please cast your +1/0/-1 vote on the following:
> 
> Currently I think this is not explicitly defined, but we wait for at least
> one peer review
> before merging code, akin to RTC.
> It would be good to publicly document the way our project work with regard
> to this for
> new and potential contributors.
> I think we have two distinct commit policies to choose from [1]:
> 
> As there's going to be lots of small changes,  to keep some velocity I am
> proposing
> to switch to Commit-Then-Review (at least temporary).
> 
> [1] From https://www.apache.org/foundation/glossary.html
> 
> 1. Commit-Then-Review
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which
> permits developers to make changes at will, with the possibility of being
> retroactively vetoed. C-T-R is an application of decision making through
> lazy consensus. The C-T-R model is useful in rapid-prototyping
> environments, but because of the lack of mandatory review it may permit
> more bugs through in daily practice than the R-T-C alternative. Compare
> R-T-C , and see the description of the voting process.
> 
> 2. Review-Then-Commit
> (Often referenced as 'RTC' or 'R-T-C'.) Commit policy which requires that
> all changes receive consensus approval in order to be committed. Compare
> C-T-R , and see the description of the voting process.
> 
> Otto
> 

Re: [VOTE] Switch commit policy to Commit-Then-Review

[Ashish Kulkarni <as...@apache.org>]

+1 for CTR

On 2018-01-13 03:06, Otto van der Schaaf <os...@apache.org> wrote: 
> Hi All,
> 
> I would like to change review policy for the incubator-pagespeed-*
> repositories.
> Please cast your +1/0/-1 vote on the following:
> 
> Currently I think this is not explicitly defined, but we wait for at least
> one peer review
> before merging code, akin to RTC.
> It would be good to publicly document the way our project work with regard
> to this for
> new and potential contributors.
> I think we have two distinct commit policies to choose from [1]:
> 
> As there's going to be lots of small changes,  to keep some velocity I am
> proposing
> to switch to Commit-Then-Review (at least temporary).
> 
> [1] From https://www.apache.org/foundation/glossary.html
> 
> 1. Commit-Then-Review
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which
> permits developers to make changes at will, with the possibility of being
> retroactively vetoed. C-T-R is an application of decision making through
> lazy consensus. The C-T-R model is useful in rapid-prototyping
> environments, but because of the lack of mandatory review it may permit
> more bugs through in daily practice than the R-T-C alternative. Compare
> R-T-C , and see the description of the voting process.
> 
> 2. Review-Then-Commit
> (Often referenced as 'RTC' or 'R-T-C'.) Commit policy which requires that
> all changes receive consensus approval in order to be committed. Compare
> C-T-R , and see the description of the voting process.
> 
> Otto
> 

Re: [VOTE] Switch commit policy to Commit-Then-Review

[Otto van der Schaaf <os...@we-amp.com>]

Thanks to all for participating in the vote.

The vote has now closed. The results are:

Binding Votes:

+1 [6]
 0 [0]
-1 [0]

The vote is successful -- the project is now in CTR-mode.
I'll document that in the wiki.

We probably want to discuss review policy again after we have merged
all the code changes for ASF policy compliance.

Otto

On Wed, Jan 17, 2018 at 6:18 PM Kees Spoelstra <ks...@we-amp.com>
wrote:

> +1
>
> On 17 January 2018 at 05:42, Leif Hedstrom <zw...@apache.org> wrote:
>
> >
> >
> > > On Jan 12, 2018, at 2:36 PM, Otto van der Schaaf <os...@apache.org>
> > wrote:
> > >
> > > Hi All,
> > >
> > > I would like to change review policy for the incubator-pagespeed-*
> > > repositories.
> > > Please cast your +1/0/-1 vote on the following:
> > >
> > > Currently I think this is not explicitly defined, but we wait for at
> > least
> > > one peer review
> > > before merging code, akin to RTC.
> > > It would be good to publicly document the way our project work with
> > regard
> > > to this for
> > > new and potential contributors.
> > > I think we have two distinct commit policies to choose from [1]:
> > >
> > > As there's going to be lots of small changes,  to keep some velocity I
> am
> > > proposing
> > > to switch to Commit-Then-Review (at least temporary).
> >
> >
> > Yeh, I’m +1 on this.
> >
> > I think long term, requiring at least one review on Github PRs would be a
> > good idea.
> >
> > — Leif
> >
> >
>

Re: [VOTE] Switch commit policy to Commit-Then-Review

[Kees Spoelstra <ks...@we-amp.com>]

+1

On 17 January 2018 at 05:42, Leif Hedstrom <zw...@apache.org> wrote:

>
>
> > On Jan 12, 2018, at 2:36 PM, Otto van der Schaaf <os...@apache.org>
> wrote:
> >
> > Hi All,
> >
> > I would like to change review policy for the incubator-pagespeed-*
> > repositories.
> > Please cast your +1/0/-1 vote on the following:
> >
> > Currently I think this is not explicitly defined, but we wait for at
> least
> > one peer review
> > before merging code, akin to RTC.
> > It would be good to publicly document the way our project work with
> regard
> > to this for
> > new and potential contributors.
> > I think we have two distinct commit policies to choose from [1]:
> >
> > As there's going to be lots of small changes,  to keep some velocity I am
> > proposing
> > to switch to Commit-Then-Review (at least temporary).
>
>
> Yeh, I’m +1 on this.
>
> I think long term, requiring at least one review on Github PRs would be a
> good idea.
>
> — Leif
>
>

Re: [VOTE] Switch commit policy to Commit-Then-Review

[Leif Hedstrom <zw...@apache.org>]

> On Jan 12, 2018, at 2:36 PM, Otto van der Schaaf <os...@apache.org> wrote:
> 
> Hi All,
> 
> I would like to change review policy for the incubator-pagespeed-*
> repositories.
> Please cast your +1/0/-1 vote on the following:
> 
> Currently I think this is not explicitly defined, but we wait for at least
> one peer review
> before merging code, akin to RTC.
> It would be good to publicly document the way our project work with regard
> to this for
> new and potential contributors.
> I think we have two distinct commit policies to choose from [1]:
> 
> As there's going to be lots of small changes,  to keep some velocity I am
> proposing
> to switch to Commit-Then-Review (at least temporary).


Yeh, I’m +1 on this.

I think long term, requiring at least one review on Github PRs would be a good idea.

— Leif

Re: [VOTE] Switch commit policy to Commit-Then-Review

[Jukka Zitting <ju...@gmail.com>]

+1

On Fri, Jan 12, 2018, 4:36 PM Otto van der Schaaf <os...@apache.org>
wrote:

> Hi All,
>
> I would like to change review policy for the incubator-pagespeed-*
> repositories.
> Please cast your +1/0/-1 vote on the following:
>
> Currently I think this is not explicitly defined, but we wait for at least
> one peer review
> before merging code, akin to RTC.
> It would be good to publicly document the way our project work with regard
> to this for
> new and potential contributors.
> I think we have two distinct commit policies to choose from [1]:
>
> As there's going to be lots of small changes,  to keep some velocity I am
> proposing
> to switch to Commit-Then-Review (at least temporary).
>
> [1] From https://www.apache.org/foundation/glossary.html
>
> 1. Commit-Then-Review
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code changes which
> permits developers to make changes at will, with the possibility of being
> retroactively vetoed. C-T-R is an application of decision making through
> lazy consensus. The C-T-R model is useful in rapid-prototyping
> environments, but because of the lack of mandatory review it may permit
> more bugs through in daily practice than the R-T-C alternative. Compare
> R-T-C , and see the description of the voting process.
>
> 2. Review-Then-Commit
> (Often referenced as 'RTC' or 'R-T-C'.) Commit policy which requires that
> all changes receive consensus approval in order to be committed. Compare
> C-T-R , and see the description of the voting process.
>
> Otto
>