You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Adrian Cole <ad...@gmail.com> on 2013/05/17 22:09:21 UTC
[VOTE] Commit-Then-Review for Codebase updates
I'm calling a vote for Commit-Then-Review for updates to our Codebase.
This implies that a Committer can merge changes they authored or
approve of without prior approval from other Committers subject to
Lazy Consensus.
Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
hours In other words, we operate the project in a way that commits
are practical to reverse up to 72 hours afterwards.
This vote is open for 72 hours
Thanks in advance for participating!
-A
http://www.apache.org/foundation/glossary.html#Codebase
http://www.apache.org/foundation/glossary.html#Committer
http://www.apache.org/foundation/glossary.html#LazyConsensus
http://www.apache.org/foundation/glossary.html#CommitThenReview
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Phillips <ap...@qrmedia.com>.
+0
Quoting Adrian Cole <ad...@gmail.com>:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
>
--
Andrew Phillips
qrmedia
Unless expressly stated otherwise, this message is confidential.
Access to this e-mail by anyone else is unauthorised. If you are
not an addressee, any disclosure or copying of the contents of
this e-mail or any action taken (or not taken) in reliance on it
is unauthorised and may be unlawful. If you are not an addressee,
please inform the sender immediately.
This message is confidential and may not be redistributed or
broadcast in whole or part in any form, including but not limited
to any form of internet transmission including email, usenet,
newsgroups, www, irc, icq, etc.
All liability for errors and viruses is disclaimed.
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Gaul <ga...@apache.org>.
+1
On Fri, May 17, 2013 at 01:09:21PM -0700, Adrian Cole wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
--
Andrew Gaul
http://gaul.org/
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Bayer <an...@gmail.com>.
Calling the vote closed - with 6 +1s, 3 +0s and 1 -1, the vote passes.
We're C-T-R now.
A.
On Mon, May 20, 2013 at 8:25 AM, Andrew Bayer <an...@gmail.com>wrote:
> +0. I'm personally in favor of R-T-C, but I don't feel anywhere near
> strongly enough about it to -1. The one thing I'd ask is that we be open to
> the possibility of shifting to R-T-C in the future if issues come up with
> C-T-R.
>
> A.
>
>
> On Sun, May 19, 2013 at 3:18 AM, Andrew Phillips <ap...@qrmedia.com>wrote:
>
>> Another thing I like of reviews is the confidence BuildHive gives to us.
>>> If
>>> we start commiting without the corresponding PRs, we'll be start seeing
>>> the
>>> build broken more often.
>>>
>>
>> I do too. And I personally can't see myself trying to make many commits
>> without waiting for BuildHive and a review which, as Everett also
>> mentioned, I've always found very instructive - indeed, being able to learn
>> from a bunch of smart programmers in this way is one of the things I really
>> enjoy about jclouds.
>>
>> Luckily, just because C-T-R may well soon be *possible* doesn't me we all
>> have to immediately switch to it. But it seems like a smart option to have
>> for some exceptional cases ;-)
>>
>> ap
>>
>
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Bayer <an...@gmail.com>.
+0. I'm personally in favor of R-T-C, but I don't feel anywhere near
strongly enough about it to -1. The one thing I'd ask is that we be open to
the possibility of shifting to R-T-C in the future if issues come up with
C-T-R.
A.
On Sun, May 19, 2013 at 3:18 AM, Andrew Phillips <ap...@qrmedia.com>wrote:
> Another thing I like of reviews is the confidence BuildHive gives to us. If
>> we start commiting without the corresponding PRs, we'll be start seeing
>> the
>> build broken more often.
>>
>
> I do too. And I personally can't see myself trying to make many commits
> without waiting for BuildHive and a review which, as Everett also
> mentioned, I've always found very instructive - indeed, being able to learn
> from a bunch of smart programmers in this way is one of the things I really
> enjoy about jclouds.
>
> Luckily, just because C-T-R may well soon be *possible* doesn't me we all
> have to immediately switch to it. But it seems like a smart option to have
> for some exceptional cases ;-)
>
> ap
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Another thing I like of reviews is the confidence BuildHive gives to us. If
> we start commiting without the corresponding PRs, we'll be start seeing the
> build broken more often.
I do too. And I personally can't see myself trying to make many
commits without waiting for BuildHive and a review which, as Everett
also mentioned, I've always found very instructive - indeed, being
able to learn from a bunch of smart programmers in this way is one of
the things I really enjoy about jclouds.
Luckily, just because C-T-R may well soon be *possible* doesn't me we
all have to immediately switch to it. But it seems like a smart option
to have for some exceptional cases ;-)
ap
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Ignasi <ig...@gmail.com>.
Another thing I like of reviews is the confidence BuildHive gives to us. If
we start commiting without the corresponding PRs, we'll be start seeing the
build broken more often.
On Sunday, 19 May 2013, Andrew Phillips wrote:
> My intention was not to interpret my vote as a veto. If in this kind
>> of vote a -1 is a veto, then I'd change it to a +0.
>>
>
> @Ignasi: Actually, if I'm interpreting things correctly, this is a
> "procedural" vote [1] which follows the majority voting process and does
> not permit vetoes. So I think you should be OK ;-)
>
> ap
>
> [1] http://www.apache.org/**foundation/voting.html<http://www.apache.org/foundation/voting.html>
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrew Phillips <ap...@qrmedia.com>.
> My intention was not to interpret my vote as a veto. If in this kind
> of vote a -1 is a veto, then I'd change it to a +0.
@Ignasi: Actually, if I'm interpreting things correctly, this is a
"procedural" vote [1] which follows the majority voting process and
does not permit vetoes. So I think you should be OK ;-)
ap
[1] http://www.apache.org/foundation/voting.html
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Andrea Turli <an...@gmail.com>.
+1
Andrea
Il giorno 18/mag/2013 23:54, "Adrian Cole" <ad...@gmail.com> ha
scritto:
> I see what you are getting at, Ignasi.
>
> With or without rules, I trust we will want each others feedback on complex
> change and probably leave a PR open and cc folks about it and/or reference
> it in a mail thread. We are on the same page.
>
> Thanks for sharing.
> -A
>
> On Saturday, May 18, 2013, Ignasi wrote:
>
> > Adrian, that makes perfect sense.
> >
> > My intention was not to interpret my vote as a veto. If in this kind
> > of vote a -1 is a veto, then I'd change it to a +0.
> >
> > What I wanted to express it that I wouldn't like to always "commit by
> > default". I'd like to have a "common sense and judgement by default",
> > and if in doubt, just ask for a review. I'm not in favor of having to
> > go through a review process when commiting simple stuff, etc.
> >
> > The intention of my vote was to express that I wouldn't like to start
> > viewing commit reverts here and there. Our commiter group is composed
> > by smart programmers, though, so I don't expect that to happen :)
> >
> > As said, if a -1 implies a veto, then I'd change my vote to +0.
> > Because I understand what is proposed and can accept it. I think CTR
> > doesn't mean that we'll start committing complex stuff with bug
> > implications without proper reviews (does it?), so I'm ok with that.
> > Common sense, then CTR if you feel the code doesn't need a review :)
> >
> >
> > Hope my position is clear now, and consider my vote a +0.
> >
> >
> >
> >
> > On 18 May 2013 03:03, David Nalley <david@gnsa.us <javascript:;>> wrote:
> > > On Fri, May 17, 2013 at 8:58 PM, Everett Toews
> > > <everett.toews@rackspace.com <javascript:;>> wrote:
> > >> +0
> > >>
> > >> I'm not sure how I feel about this but am willing to go along with the
> > experiment. Personally I've learned a lot from the reviews I've got. It
> > hasn't always been easy but it's ultimately rewarding. In areas that I'm
> > unsure about I'll likely continue to seek out reviews before committing.
> > >>
> > >
> > > I think CTR allows you to move faster (as Olivier pointed out), and if
> > > you grow a community that is really interested in quality they tend to
> > > look at commits and also ask if they aren't sure, or just as a good
> > > practice, but aren't necessarily gated by it.
> > >
> > > --David
> >
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Adrian Cole <ad...@gmail.com>.
I see what you are getting at, Ignasi.
With or without rules, I trust we will want each others feedback on complex
change and probably leave a PR open and cc folks about it and/or reference
it in a mail thread. We are on the same page.
Thanks for sharing.
-A
On Saturday, May 18, 2013, Ignasi wrote:
> Adrian, that makes perfect sense.
>
> My intention was not to interpret my vote as a veto. If in this kind
> of vote a -1 is a veto, then I'd change it to a +0.
>
> What I wanted to express it that I wouldn't like to always "commit by
> default". I'd like to have a "common sense and judgement by default",
> and if in doubt, just ask for a review. I'm not in favor of having to
> go through a review process when commiting simple stuff, etc.
>
> The intention of my vote was to express that I wouldn't like to start
> viewing commit reverts here and there. Our commiter group is composed
> by smart programmers, though, so I don't expect that to happen :)
>
> As said, if a -1 implies a veto, then I'd change my vote to +0.
> Because I understand what is proposed and can accept it. I think CTR
> doesn't mean that we'll start committing complex stuff with bug
> implications without proper reviews (does it?), so I'm ok with that.
> Common sense, then CTR if you feel the code doesn't need a review :)
>
>
> Hope my position is clear now, and consider my vote a +0.
>
>
>
>
> On 18 May 2013 03:03, David Nalley <david@gnsa.us <javascript:;>> wrote:
> > On Fri, May 17, 2013 at 8:58 PM, Everett Toews
> > <everett.toews@rackspace.com <javascript:;>> wrote:
> >> +0
> >>
> >> I'm not sure how I feel about this but am willing to go along with the
> experiment. Personally I've learned a lot from the reviews I've got. It
> hasn't always been easy but it's ultimately rewarding. In areas that I'm
> unsure about I'll likely continue to seek out reviews before committing.
> >>
> >
> > I think CTR allows you to move faster (as Olivier pointed out), and if
> > you grow a community that is really interested in quality they tend to
> > look at commits and also ask if they aren't sure, or just as a good
> > practice, but aren't necessarily gated by it.
> >
> > --David
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Ignasi <ig...@gmail.com>.
Adrian, that makes perfect sense.
My intention was not to interpret my vote as a veto. If in this kind
of vote a -1 is a veto, then I'd change it to a +0.
What I wanted to express it that I wouldn't like to always "commit by
default". I'd like to have a "common sense and judgement by default",
and if in doubt, just ask for a review. I'm not in favor of having to
go through a review process when commiting simple stuff, etc.
The intention of my vote was to express that I wouldn't like to start
viewing commit reverts here and there. Our commiter group is composed
by smart programmers, though, so I don't expect that to happen :)
As said, if a -1 implies a veto, then I'd change my vote to +0.
Because I understand what is proposed and can accept it. I think CTR
doesn't mean that we'll start committing complex stuff with bug
implications without proper reviews (does it?), so I'm ok with that.
Common sense, then CTR if you feel the code doesn't need a review :)
Hope my position is clear now, and consider my vote a +0.
On 18 May 2013 03:03, David Nalley <da...@gnsa.us> wrote:
> On Fri, May 17, 2013 at 8:58 PM, Everett Toews
> <ev...@rackspace.com> wrote:
>> +0
>>
>> I'm not sure how I feel about this but am willing to go along with the experiment. Personally I've learned a lot from the reviews I've got. It hasn't always been easy but it's ultimately rewarding. In areas that I'm unsure about I'll likely continue to seek out reviews before committing.
>>
>
> I think CTR allows you to move faster (as Olivier pointed out), and if
> you grow a community that is really interested in quality they tend to
> look at commits and also ask if they aren't sure, or just as a good
> practice, but aren't necessarily gated by it.
>
> --David
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by David Nalley <da...@gnsa.us>.
On Fri, May 17, 2013 at 8:58 PM, Everett Toews
<ev...@rackspace.com> wrote:
> +0
>
> I'm not sure how I feel about this but am willing to go along with the experiment. Personally I've learned a lot from the reviews I've got. It hasn't always been easy but it's ultimately rewarding. In areas that I'm unsure about I'll likely continue to seek out reviews before committing.
>
I think CTR allows you to move faster (as Olivier pointed out), and if
you grow a community that is really interested in quality they tend to
look at commits and also ask if they aren't sure, or just as a good
practice, but aren't necessarily gated by it.
--David
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Everett Toews <ev...@RACKSPACE.COM>.
+0
I'm not sure how I feel about this but am willing to go along with the experiment. Personally I've learned a lot from the reviews I've got. It hasn't always been easy but it's ultimately rewarding. In areas that I'm unsure about I'll likely continue to seek out reviews before committing.
Everett
On May 17, 2013, at 3:09 PM, Adrian Cole wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Matt Stephenson <ma...@mattstep.net>.
+1
On Fri, May 17, 2013 at 1:09 PM, Adrian Cole <ad...@gmail.com>wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Adrian Cole <ad...@gmail.com>.
Sorry accidentally sent. Anyway, I doubt you are interested in reviewing
routine code changes by folks who've already vetted themselves as
committers. Honestly, a lot of +1s for maintenance are just "I trust you"
Just because we vote to default to C-T-R doesn't mean we shouldn't review
between ourselves for important or wide scoped problems. The goal of this
vote is to establish the base case, not to stop us from collaborating :)
Make sense?
-A
On Friday, May 17, 2013, Adrian Cole wrote:
> So just to understand the context. Let me try and play this back.
>
> Committers have been reviewing (or +1ing) each-others commits pre-ASF
> for the last several months. More clearly, we've merged after
> somebody who has commit rights and didn't author it +1s it. Your case
> is that since you've not perceived a problem with the old process, we
> should inherit that into the ASF.
>
> This sounds reasonable, however it isn't a vote for Review-Then-Commit
> :) R-T-C specifies consensus approval
>
>
>
>
>
>
> On Fri, May 17, 2013 at 4:35 PM, Ignasi <ignasi.barrera@gmail.com<javascript:;>>
> wrote:
> > -1
> >
> > Code reviews improve code quality, and between committers, (which usually
> > follow to the jclouds coding best practices) they should be pretty
> > straightforward. I like the idea that every push has had more than an eye
> > on it.
> >
> > Also I think reviews don't delay the push too much; at most a day or two,
> > and till now (afaik) we haven't had deadlines where this delay could be a
> > problem.
> >
> > I feel that time consuming reviews and problematic PRs don't fall into
> the
> > "commiter's commits" group.
> > El 18/05/2013 00:44, "Suresh Marru" <smarru@apache.org <javascript:;>>
> escribió:
> >
> >> + 1.
> >>
> >> Suresh
> >>
> >> On May 17, 2013, at 4:09 PM, Adrian Cole <adrian.f.cole@gmail.com<javascript:;>>
> wrote:
> >>
> >> > I'm calling a vote for Commit-Then-Review for updates to our Codebase.
> >> >
> >> > This implies that a Committer can merge changes they authored or
> >> > approve of without prior approval from other Committers subject to
> >> > Lazy Consensus.
> >> >
> >> > Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> >> > hours In other words, we operate the project in a way that commits
> >> > are practical to reverse up to 72 hours afterwards.
> >> >
> >> > This vote is open for 72 hours
> >> >
> >> > Thanks in advance for participating!
> >> > -A
> >> >
> >> > http://www.apache.org/foundation/glossary.html#Codebase
> >> > http://www.apache.org/foundation/glossary.html#Committer
> >> > http://www.apache.org/foundation/glossary.html#LazyConsensus
> >> > http://www.apache.org/foundation/glossary.html#CommitThenReview
> >>
> >>
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Adrian Cole <ad...@gmail.com>.
So just to understand the context. Let me try and play this back.
Committers have been reviewing (or +1ing) each-others commits pre-ASF
for the last several months. More clearly, we've merged after
somebody who has commit rights and didn't author it +1s it. Your case
is that since you've not perceived a problem with the old process, we
should inherit that into the ASF.
This sounds reasonable, however it isn't a vote for Review-Then-Commit
:) R-T-C specifies consensus approval
On Fri, May 17, 2013 at 4:35 PM, Ignasi <ig...@gmail.com> wrote:
> -1
>
> Code reviews improve code quality, and between committers, (which usually
> follow to the jclouds coding best practices) they should be pretty
> straightforward. I like the idea that every push has had more than an eye
> on it.
>
> Also I think reviews don't delay the push too much; at most a day or two,
> and till now (afaik) we haven't had deadlines where this delay could be a
> problem.
>
> I feel that time consuming reviews and problematic PRs don't fall into the
> "commiter's commits" group.
> El 18/05/2013 00:44, "Suresh Marru" <sm...@apache.org> escribió:
>
>> + 1.
>>
>> Suresh
>>
>> On May 17, 2013, at 4:09 PM, Adrian Cole <ad...@gmail.com> wrote:
>>
>> > I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>> >
>> > This implies that a Committer can merge changes they authored or
>> > approve of without prior approval from other Committers subject to
>> > Lazy Consensus.
>> >
>> > Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
>> > hours In other words, we operate the project in a way that commits
>> > are practical to reverse up to 72 hours afterwards.
>> >
>> > This vote is open for 72 hours
>> >
>> > Thanks in advance for participating!
>> > -A
>> >
>> > http://www.apache.org/foundation/glossary.html#Codebase
>> > http://www.apache.org/foundation/glossary.html#Committer
>> > http://www.apache.org/foundation/glossary.html#LazyConsensus
>> > http://www.apache.org/foundation/glossary.html#CommitThenReview
>>
>>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Ignasi <ig...@gmail.com>.
-1
Code reviews improve code quality, and between committers, (which usually
follow to the jclouds coding best practices) they should be pretty
straightforward. I like the idea that every push has had more than an eye
on it.
Also I think reviews don't delay the push too much; at most a day or two,
and till now (afaik) we haven't had deadlines where this delay could be a
problem.
I feel that time consuming reviews and problematic PRs don't fall into the
"commiter's commits" group.
El 18/05/2013 00:44, "Suresh Marru" <sm...@apache.org> escribió:
> + 1.
>
> Suresh
>
> On May 17, 2013, at 4:09 PM, Adrian Cole <ad...@gmail.com> wrote:
>
> > I'm calling a vote for Commit-Then-Review for updates to our Codebase.
> >
> > This implies that a Committer can merge changes they authored or
> > approve of without prior approval from other Committers subject to
> > Lazy Consensus.
> >
> > Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> > hours In other words, we operate the project in a way that commits
> > are practical to reverse up to 72 hours afterwards.
> >
> > This vote is open for 72 hours
> >
> > Thanks in advance for participating!
> > -A
> >
> > http://www.apache.org/foundation/glossary.html#Codebase
> > http://www.apache.org/foundation/glossary.html#Committer
> > http://www.apache.org/foundation/glossary.html#LazyConsensus
> > http://www.apache.org/foundation/glossary.html#CommitThenReview
>
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Suresh Marru <sm...@apache.org>.
+ 1.
Suresh
On May 17, 2013, at 4:09 PM, Adrian Cole <ad...@gmail.com> wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Olivier Lamy <ol...@apache.org>.
+1 (so much faster model IMHO )
Olivier
On May 18, 2013 6:09 AM, "Adrian Cole" <ad...@gmail.com> wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview
>
Re: [VOTE] Commit-Then-Review for Codebase updates
Posted by Adrian Cole <ad...@gmail.com>.
+1
On Fri, May 17, 2013 at 1:09 PM, Adrian Cole <ad...@gmail.com> wrote:
> I'm calling a vote for Commit-Then-Review for updates to our Codebase.
>
> This implies that a Committer can merge changes they authored or
> approve of without prior approval from other Committers subject to
> Lazy Consensus.
>
> Voting +1 also clarifies the period of Lazy Consensus to maximum of 72
> hours In other words, we operate the project in a way that commits
> are practical to reverse up to 72 hours afterwards.
>
> This vote is open for 72 hours
>
> Thanks in advance for participating!
> -A
>
> http://www.apache.org/foundation/glossary.html#Codebase
> http://www.apache.org/foundation/glossary.html#Committer
> http://www.apache.org/foundation/glossary.html#LazyConsensus
> http://www.apache.org/foundation/glossary.html#CommitThenReview