[Proposal] PR voting process changes

[Nate Smith <na...@apache.org>]

Hello,

From my own experience and also in talking directly with a few committers
to the project the requirement for three +1's from committers should be
reviewed.

My understanding is that other projects in the ASF simply require one vote
and provide some time for review by others prior to merging (such as a
24-48 hour period). However more emphasis is placed on refining code in
preparation for releases.

As it stands today we require at least three +1's before merge, and there
is no time requirement.

Since we are a growing community, and the goal is to develop more code
contributors I think it is important to bring this up for review in hopes
that we can adopt something that allows faster iterations with a strong
focus on polishing for future releases.

- Nathanael

Re: [Proposal] PR voting process changes

[Cesar Berho <ce...@apache.org>]

+1  on the 48 hrs period.

On Fri, Sep 22, 2017 at 10:15 AM, Gonzalez, Victor <
victor.gonzalez@intel.com> wrote:

> +1 with 48 hours period
>
> Sent from my iPhone
>
> > On Sep 21, 2017, at 3:52 PM, Jon Zeolla <Jo...@apache.org> wrote:
> >
> > I agree, at least one +1 from a committer as a minimum bar is pretty
> > reasonable.  For bigger changes usually having more people review and
> test
> > makes sense, but I've seen that handled as more of a one off.
> >
> > I'm usually in favor of a 24 hour wait as well, but could see it go
> either
> > way here.
> >
> > Jon
> >
> >> On Thu, Sep 21, 2017, 16:44 <ja...@apache.org> wrote:
> >>
> >> I would recommend to make contributing to Spot as easily as possible
> >> because any hurdle or obstacle will make contributing harder and thus
> will
> >> discourage potential long term contributors.
> >>
> >> Pretty much all other projects that I’m involved with at ASF are
> following
> >> something in the lines of what Nate is describing. Anyone on the
> internet
> >> can submit a patch and all it takes is a single committer who does
> review
> >> and then the patch is merged to master branch. Some projects do a “cool
> >> off" window before the “review” and “merge” to make sure that other
> >> committers have time to jump in - projects like Hadoop and Hive tend to
> >> give 24 hours, projects like Sqoop or Flume simply commit immediately.
> Any
> >> other committer however have always a chance to jump in and pretty much
> >> VETO the patch — provided there is a good explanation for the push back.
> >>
> >> Jarcec
> >>
> >>> On Sep 21, 2017, at 1:15 PM, Michael Ridley <mr...@cloudera.com>
> >> wrote:
> >>>
> >>> Sounds like a good approach.  I'm all in favor of following a process
> >> that
> >>> works for other ASF projects.
> >>>
> >>> Speaking of votes by committer, I think any vote would be recorded as
> >>> binding or non-binding based on committer status.  I am not a committer
> >> so
> >>> I always make sure to mark mine as non-binding.
> >>>
> >>> Michael
> >>>
> >>> On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com>
> >> wrote:
> >>>
> >>>> Also,
> >>>>
> >>>> As a point of consideration it's good to highlight that in such a
> >> scenario
> >>>> where a +1 is given and 48 hours to review prior to merge, any -1
> should
> >>>> reset the vote in my mind. Votes of such nature would have to be
> >> restricted
> >>>> to committers on the project.
> >>>>
> >>>> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> From my own experience and also in talking directly with a few
> >> committers
> >>>>> to the project the requirement for three +1's from committers should
> be
> >>>>> reviewed.
> >>>>>
> >>>>> My understanding is that other projects in the ASF simply require one
> >>>> vote
> >>>>> and provide some time for review by others prior to merging (such as
> a
> >>>>> 24-48 hour period). However more emphasis is placed on refining code
> in
> >>>>> preparation for releases.
> >>>>>
> >>>>> As it stands today we require at least three +1's before merge, and
> >> there
> >>>>> is no time requirement.
> >>>>>
> >>>>> Since we are a growing community, and the goal is to develop more
> code
> >>>>> contributors I think it is important to bring this up for review in
> >> hopes
> >>>>> that we can adopt something that allows faster iterations with a
> strong
> >>>>> focus on polishing for future releases.
> >>>>>
> >>>>> - Nathanael
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Michael Ridley <mr...@cloudera.com>
> >>> office: (650) 352-1337
> >>> mobile: (571) 438-2420
> >>> Senior Solutions Architect
> >>> Cloudera
> >>
> >> --
> >
> > Jon
>

Re: [Proposal] PR voting process changes

["Gonzalez, Victor" <vi...@intel.com>]

+1 with 48 hours period

Sent from my iPhone

> On Sep 21, 2017, at 3:52 PM, Jon Zeolla <Jo...@apache.org> wrote:
> 
> I agree, at least one +1 from a committer as a minimum bar is pretty
> reasonable.  For bigger changes usually having more people review and test
> makes sense, but I've seen that handled as more of a one off.
> 
> I'm usually in favor of a 24 hour wait as well, but could see it go either
> way here.
> 
> Jon
> 
>> On Thu, Sep 21, 2017, 16:44 <ja...@apache.org> wrote:
>> 
>> I would recommend to make contributing to Spot as easily as possible
>> because any hurdle or obstacle will make contributing harder and thus will
>> discourage potential long term contributors.
>> 
>> Pretty much all other projects that I’m involved with at ASF are following
>> something in the lines of what Nate is describing. Anyone on the internet
>> can submit a patch and all it takes is a single committer who does review
>> and then the patch is merged to master branch. Some projects do a “cool
>> off" window before the “review” and “merge” to make sure that other
>> committers have time to jump in - projects like Hadoop and Hive tend to
>> give 24 hours, projects like Sqoop or Flume simply commit immediately. Any
>> other committer however have always a chance to jump in and pretty much
>> VETO the patch — provided there is a good explanation for the push back.
>> 
>> Jarcec
>> 
>>> On Sep 21, 2017, at 1:15 PM, Michael Ridley <mr...@cloudera.com>
>> wrote:
>>> 
>>> Sounds like a good approach.  I'm all in favor of following a process
>> that
>>> works for other ASF projects.
>>> 
>>> Speaking of votes by committer, I think any vote would be recorded as
>>> binding or non-binding based on committer status.  I am not a committer
>> so
>>> I always make sure to mark mine as non-binding.
>>> 
>>> Michael
>>> 
>>> On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com>
>> wrote:
>>> 
>>>> Also,
>>>> 
>>>> As a point of consideration it's good to highlight that in such a
>> scenario
>>>> where a +1 is given and 48 hours to review prior to merge, any -1 should
>>>> reset the vote in my mind. Votes of such nature would have to be
>> restricted
>>>> to committers on the project.
>>>> 
>>>> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org>
>> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> From my own experience and also in talking directly with a few
>> committers
>>>>> to the project the requirement for three +1's from committers should be
>>>>> reviewed.
>>>>> 
>>>>> My understanding is that other projects in the ASF simply require one
>>>> vote
>>>>> and provide some time for review by others prior to merging (such as a
>>>>> 24-48 hour period). However more emphasis is placed on refining code in
>>>>> preparation for releases.
>>>>> 
>>>>> As it stands today we require at least three +1's before merge, and
>> there
>>>>> is no time requirement.
>>>>> 
>>>>> Since we are a growing community, and the goal is to develop more code
>>>>> contributors I think it is important to bring this up for review in
>> hopes
>>>>> that we can adopt something that allows faster iterations with a strong
>>>>> focus on polishing for future releases.
>>>>> 
>>>>> - Nathanael
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Michael Ridley <mr...@cloudera.com>
>>> office: (650) 352-1337
>>> mobile: (571) 438-2420
>>> Senior Solutions Architect
>>> Cloudera
>> 
>> --
> 
> Jon

Re: [Proposal] PR voting process changes

[Jon Zeolla <Jo...@apache.org>]

I agree, at least one +1 from a committer as a minimum bar is pretty
reasonable.  For bigger changes usually having more people review and test
makes sense, but I've seen that handled as more of a one off.

I'm usually in favor of a 24 hour wait as well, but could see it go either
way here.

Jon

On Thu, Sep 21, 2017, 16:44 <ja...@apache.org> wrote:

> I would recommend to make contributing to Spot as easily as possible
> because any hurdle or obstacle will make contributing harder and thus will
> discourage potential long term contributors.
>
> Pretty much all other projects that I’m involved with at ASF are following
> something in the lines of what Nate is describing. Anyone on the internet
> can submit a patch and all it takes is a single committer who does review
> and then the patch is merged to master branch. Some projects do a “cool
> off" window before the “review” and “merge” to make sure that other
> committers have time to jump in - projects like Hadoop and Hive tend to
> give 24 hours, projects like Sqoop or Flume simply commit immediately. Any
> other committer however have always a chance to jump in and pretty much
> VETO the patch — provided there is a good explanation for the push back.
>
> Jarcec
>
> > On Sep 21, 2017, at 1:15 PM, Michael Ridley <mr...@cloudera.com>
> wrote:
> >
> > Sounds like a good approach.  I'm all in favor of following a process
> that
> > works for other ASF projects.
> >
> > Speaking of votes by committer, I think any vote would be recorded as
> > binding or non-binding based on committer status.  I am not a committer
> so
> > I always make sure to mark mine as non-binding.
> >
> > Michael
> >
> > On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com>
> wrote:
> >
> >> Also,
> >>
> >> As a point of consideration it's good to highlight that in such a
> scenario
> >> where a +1 is given and 48 hours to review prior to merge, any -1 should
> >> reset the vote in my mind. Votes of such nature would have to be
> restricted
> >> to committers on the project.
> >>
> >> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org>
> wrote:
> >>
> >>> Hello,
> >>>
> >>> From my own experience and also in talking directly with a few
> committers
> >>> to the project the requirement for three +1's from committers should be
> >>> reviewed.
> >>>
> >>> My understanding is that other projects in the ASF simply require one
> >> vote
> >>> and provide some time for review by others prior to merging (such as a
> >>> 24-48 hour period). However more emphasis is placed on refining code in
> >>> preparation for releases.
> >>>
> >>> As it stands today we require at least three +1's before merge, and
> there
> >>> is no time requirement.
> >>>
> >>> Since we are a growing community, and the goal is to develop more code
> >>> contributors I think it is important to bring this up for review in
> hopes
> >>> that we can adopt something that allows faster iterations with a strong
> >>> focus on polishing for future releases.
> >>>
> >>> - Nathanael
> >>>
> >>
> >
> >
> >
> > --
> > Michael Ridley <mr...@cloudera.com>
> > office: (650) 352-1337
> > mobile: (571) 438-2420
> > Senior Solutions Architect
> > Cloudera
>
> --

Jon

Re: [Proposal] PR voting process changes

[Michael Ridley <mr...@cloudera.com>]

I definitely agree with the intent of making it as low friction as
possible.  I hope this isn't counter to that goal, but I would propose
something like a 48 hour window here only because the project is still
fairly young and there isn't a lot of established institutional wisdom or
best practices so it might be necessary to figure out how to best integrate
contributions.  My understanding is that many of the committers and PMC
members are only nominally experienced with ASF so I think there will be a
learning period.  I would expect in a year or two that instant commit is
probably going to be the right thing for Spot.

My (non-binding) two cents :-)

Michael

On Thu, Sep 21, 2017 at 4:44 PM, <ja...@apache.org> wrote:

> I would recommend to make contributing to Spot as easily as possible
> because any hurdle or obstacle will make contributing harder and thus will
> discourage potential long term contributors.
>
> Pretty much all other projects that I’m involved with at ASF are following
> something in the lines of what Nate is describing. Anyone on the internet
> can submit a patch and all it takes is a single committer who does review
> and then the patch is merged to master branch. Some projects do a “cool
> off" window before the “review” and “merge” to make sure that other
> committers have time to jump in - projects like Hadoop and Hive tend to
> give 24 hours, projects like Sqoop or Flume simply commit immediately. Any
> other committer however have always a chance to jump in and pretty much
> VETO the patch — provided there is a good explanation for the push back.
>
> Jarcec
>
> > On Sep 21, 2017, at 1:15 PM, Michael Ridley <mr...@cloudera.com>
> wrote:
> >
> > Sounds like a good approach.  I'm all in favor of following a process
> that
> > works for other ASF projects.
> >
> > Speaking of votes by committer, I think any vote would be recorded as
> > binding or non-binding based on committer status.  I am not a committer
> so
> > I always make sure to mark mine as non-binding.
> >
> > Michael
> >
> > On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com>
> wrote:
> >
> >> Also,
> >>
> >> As a point of consideration it's good to highlight that in such a
> scenario
> >> where a +1 is given and 48 hours to review prior to merge, any -1 should
> >> reset the vote in my mind. Votes of such nature would have to be
> restricted
> >> to committers on the project.
> >>
> >> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org>
> wrote:
> >>
> >>> Hello,
> >>>
> >>> From my own experience and also in talking directly with a few
> committers
> >>> to the project the requirement for three +1's from committers should be
> >>> reviewed.
> >>>
> >>> My understanding is that other projects in the ASF simply require one
> >> vote
> >>> and provide some time for review by others prior to merging (such as a
> >>> 24-48 hour period). However more emphasis is placed on refining code in
> >>> preparation for releases.
> >>>
> >>> As it stands today we require at least three +1's before merge, and
> there
> >>> is no time requirement.
> >>>
> >>> Since we are a growing community, and the goal is to develop more code
> >>> contributors I think it is important to bring this up for review in
> hopes
> >>> that we can adopt something that allows faster iterations with a strong
> >>> focus on polishing for future releases.
> >>>
> >>> - Nathanael
> >>>
> >>
> >
> >
> >
> > --
> > Michael Ridley <mr...@cloudera.com>
> > office: (650) 352-1337
> > mobile: (571) 438-2420
> > Senior Solutions Architect
> > Cloudera
>
>


-- 
Michael Ridley <mr...@cloudera.com>
office: (650) 352-1337
mobile: (571) 438-2420
Senior Solutions Architect
Cloudera

Re: [Proposal] PR voting process changes

[ja...@apache.org]

I would recommend to make contributing to Spot as easily as possible because any hurdle or obstacle will make contributing harder and thus will discourage potential long term contributors. 

Pretty much all other projects that I’m involved with at ASF are following something in the lines of what Nate is describing. Anyone on the internet can submit a patch and all it takes is a single committer who does review and then the patch is merged to master branch. Some projects do a “cool off" window before the “review” and “merge” to make sure that other committers have time to jump in - projects like Hadoop and Hive tend to give 24 hours, projects like Sqoop or Flume simply commit immediately. Any other committer however have always a chance to jump in and pretty much VETO the patch — provided there is a good explanation for the push back.

Jarcec

> On Sep 21, 2017, at 1:15 PM, Michael Ridley <mr...@cloudera.com> wrote:
> 
> Sounds like a good approach.  I'm all in favor of following a process that
> works for other ASF projects.
> 
> Speaking of votes by committer, I think any vote would be recorded as
> binding or non-binding based on committer status.  I am not a committer so
> I always make sure to mark mine as non-binding.
> 
> Michael
> 
> On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com> wrote:
> 
>> Also,
>> 
>> As a point of consideration it's good to highlight that in such a scenario
>> where a +1 is given and 48 hours to review prior to merge, any -1 should
>> reset the vote in my mind. Votes of such nature would have to be restricted
>> to committers on the project.
>> 
>> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org> wrote:
>> 
>>> Hello,
>>> 
>>> From my own experience and also in talking directly with a few committers
>>> to the project the requirement for three +1's from committers should be
>>> reviewed.
>>> 
>>> My understanding is that other projects in the ASF simply require one
>> vote
>>> and provide some time for review by others prior to merging (such as a
>>> 24-48 hour period). However more emphasis is placed on refining code in
>>> preparation for releases.
>>> 
>>> As it stands today we require at least three +1's before merge, and there
>>> is no time requirement.
>>> 
>>> Since we are a growing community, and the goal is to develop more code
>>> contributors I think it is important to bring this up for review in hopes
>>> that we can adopt something that allows faster iterations with a strong
>>> focus on polishing for future releases.
>>> 
>>> - Nathanael
>>> 
>> 
> 
> 
> 
> -- 
> Michael Ridley <mr...@cloudera.com>
> office: (650) 352-1337
> mobile: (571) 438-2420
> Senior Solutions Architect
> Cloudera

Re: [Proposal] PR voting process changes

[Michael Ridley <mr...@cloudera.com>]

Sounds like a good approach.  I'm all in favor of following a process that
works for other ASF projects.

Speaking of votes by committer, I think any vote would be recorded as
binding or non-binding based on committer status.  I am not a committer so
I always make sure to mark mine as non-binding.

Michael

On Thu, Sep 21, 2017 at 1:28 PM, Nate Smith <na...@gmail.com> wrote:

> Also,
>
> As a point of consideration it's good to highlight that in such a scenario
> where a +1 is given and 48 hours to review prior to merge, any -1 should
> reset the vote in my mind. Votes of such nature would have to be restricted
> to committers on the project.
>
> On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org> wrote:
>
> > Hello,
> >
> > From my own experience and also in talking directly with a few committers
> > to the project the requirement for three +1's from committers should be
> > reviewed.
> >
> > My understanding is that other projects in the ASF simply require one
> vote
> > and provide some time for review by others prior to merging (such as a
> > 24-48 hour period). However more emphasis is placed on refining code in
> > preparation for releases.
> >
> > As it stands today we require at least three +1's before merge, and there
> > is no time requirement.
> >
> > Since we are a growing community, and the goal is to develop more code
> > contributors I think it is important to bring this up for review in hopes
> > that we can adopt something that allows faster iterations with a strong
> > focus on polishing for future releases.
> >
> > - Nathanael
> >
>



-- 
Michael Ridley <mr...@cloudera.com>
office: (650) 352-1337
mobile: (571) 438-2420
Senior Solutions Architect
Cloudera

Re: [Proposal] PR voting process changes

[Nate Smith <na...@gmail.com>]

Also,

As a point of consideration it's good to highlight that in such a scenario
where a +1 is given and 48 hours to review prior to merge, any -1 should
reset the vote in my mind. Votes of such nature would have to be restricted
to committers on the project.

On Thu, Sep 21, 2017 at 10:22 AM, Nate Smith <na...@apache.org> wrote:

> Hello,
>
> From my own experience and also in talking directly with a few committers
> to the project the requirement for three +1's from committers should be
> reviewed.
>
> My understanding is that other projects in the ASF simply require one vote
> and provide some time for review by others prior to merging (such as a
> 24-48 hour period). However more emphasis is placed on refining code in
> preparation for releases.
>
> As it stands today we require at least three +1's before merge, and there
> is no time requirement.
>
> Since we are a growing community, and the goal is to develop more code
> contributors I think it is important to bring this up for review in hopes
> that we can adopt something that allows faster iterations with a strong
> focus on polishing for future releases.
>
> - Nathanael
>