You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mnemonic.apache.org by "Wang, Yanping" <ya...@intel.com> on 2016/04/14 20:07:05 UTC

Re: Code review tools for Arrow patches

I agree, we need a code review tools as well for Mnemonic. We are going to submit large patches. I include mnemonic dev list here for discussion. 

Thanks

> On Apr 14, 2016, at 10:39 AM, Wes McKinney <we...@cloudera.com> wrote:
> 
> hello all,
> 
> We're reaching a junction where larger patches to the Arrow codebase
> will become more frequent, and effective code reviews will be
> important part of maintaining a high quality project going forward.
> 
> In general, the GitHub pull request UI is not generally thought of as
> very productive in large code reviews (some recent exposition on this
> topic: http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/).
> Many large engineering teams prefer such (git-centric) tools as
> Gerrit, though there are other code review tools available.
> 
> I don't think we are at a point where a particular code review process
> should be enforced, but more that we should have more tools available
> for groups of Arrow committers who wish to collaborate in a particular
> way.
> 
> As I'm familiar with Gerrit from working on Apache projects that
> Cloudera's involved with, my bias would be to try to get an instance
> set up so that larger patches can be reviewed in a more detailed and
> transactional way. For example: we could use gerrit.cloudera.org (like
> Kudu and Impala), but I would be happy to use any infrastructure
> provider.
> 
> There has been some resistance / inaction within the ASF to create an
> ASF-managed Gerrit instance:
> https://issues.apache.org/jira/browse/INFRA-2205.
> 
> I'm interested to hear other perspectives.
> 
> Thanks,
> Wes

Re: Code review tools for Arrow patches

Posted by Jacques Nadeau <ja...@apache.org>.
My preference in order is:

1. Gerrit
2. Review board
3. GH PRs

The lack of transactionality and good history makes GH PRs frequently
inadequate. (We used them as the default on Drill for the last year.) The
per comment email model is also ridiculous.

On Thu, Apr 14, 2016 at 3:27 PM, Henry Saputra <he...@gmail.com>
wrote:

> How about using Github Pull Requests as mechanism to do review?
>
> So, all patches need to be done via Github mirror PRs, similar to Flink and
> Spark and other new projects have been doing.
>
> At AsterixDB we did Gerrit and has to do some tooling to make sure it
> comply with ASF way.
>
> - Henry
>
> On Thu, Apr 14, 2016 at 11:07 AM, Wang, Yanping <ya...@intel.com>
> wrote:
>
> > I agree, we need a code review tools as well for Mnemonic. We are going
> to
> > submit large patches. I include mnemonic dev list here for discussion.
> >
> > Thanks
> >
> > > On Apr 14, 2016, at 10:39 AM, Wes McKinney <we...@cloudera.com> wrote:
> > >
> > > hello all,
> > >
> > > We're reaching a junction where larger patches to the Arrow codebase
> > > will become more frequent, and effective code reviews will be
> > > important part of maintaining a high quality project going forward.
> > >
> > > In general, the GitHub pull request UI is not generally thought of as
> > > very productive in large code reviews (some recent exposition on this
> > > topic:
> >
> http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/
> > ).
> > > Many large engineering teams prefer such (git-centric) tools as
> > > Gerrit, though there are other code review tools available.
> > >
> > > I don't think we are at a point where a particular code review process
> > > should be enforced, but more that we should have more tools available
> > > for groups of Arrow committers who wish to collaborate in a particular
> > > way.
> > >
> > > As I'm familiar with Gerrit from working on Apache projects that
> > > Cloudera's involved with, my bias would be to try to get an instance
> > > set up so that larger patches can be reviewed in a more detailed and
> > > transactional way. For example: we could use gerrit.cloudera.org (like
> > > Kudu and Impala), but I would be happy to use any infrastructure
> > > provider.
> > >
> > > There has been some resistance / inaction within the ASF to create an
> > > ASF-managed Gerrit instance:
> > > https://issues.apache.org/jira/browse/INFRA-2205.
> > >
> > > I'm interested to hear other perspectives.
> > >
> > > Thanks,
> > > Wes
> >
>

Re: Code review tools for Arrow patches

Posted by Jacques Nadeau <ja...@apache.org>.
My preference in order is:

1. Gerrit
2. Review board
3. GH PRs

The lack of transactionality and good history makes GH PRs frequently
inadequate. (We used them as the default on Drill for the last year.) The
per comment email model is also ridiculous.

On Thu, Apr 14, 2016 at 3:27 PM, Henry Saputra <he...@gmail.com>
wrote:

> How about using Github Pull Requests as mechanism to do review?
>
> So, all patches need to be done via Github mirror PRs, similar to Flink and
> Spark and other new projects have been doing.
>
> At AsterixDB we did Gerrit and has to do some tooling to make sure it
> comply with ASF way.
>
> - Henry
>
> On Thu, Apr 14, 2016 at 11:07 AM, Wang, Yanping <ya...@intel.com>
> wrote:
>
> > I agree, we need a code review tools as well for Mnemonic. We are going
> to
> > submit large patches. I include mnemonic dev list here for discussion.
> >
> > Thanks
> >
> > > On Apr 14, 2016, at 10:39 AM, Wes McKinney <we...@cloudera.com> wrote:
> > >
> > > hello all,
> > >
> > > We're reaching a junction where larger patches to the Arrow codebase
> > > will become more frequent, and effective code reviews will be
> > > important part of maintaining a high quality project going forward.
> > >
> > > In general, the GitHub pull request UI is not generally thought of as
> > > very productive in large code reviews (some recent exposition on this
> > > topic:
> >
> http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/
> > ).
> > > Many large engineering teams prefer such (git-centric) tools as
> > > Gerrit, though there are other code review tools available.
> > >
> > > I don't think we are at a point where a particular code review process
> > > should be enforced, but more that we should have more tools available
> > > for groups of Arrow committers who wish to collaborate in a particular
> > > way.
> > >
> > > As I'm familiar with Gerrit from working on Apache projects that
> > > Cloudera's involved with, my bias would be to try to get an instance
> > > set up so that larger patches can be reviewed in a more detailed and
> > > transactional way. For example: we could use gerrit.cloudera.org (like
> > > Kudu and Impala), but I would be happy to use any infrastructure
> > > provider.
> > >
> > > There has been some resistance / inaction within the ASF to create an
> > > ASF-managed Gerrit instance:
> > > https://issues.apache.org/jira/browse/INFRA-2205.
> > >
> > > I'm interested to hear other perspectives.
> > >
> > > Thanks,
> > > Wes
> >
>

Re: Code review tools for Arrow patches

Posted by Henry Saputra <he...@gmail.com>.
How about using Github Pull Requests as mechanism to do review?

So, all patches need to be done via Github mirror PRs, similar to Flink and
Spark and other new projects have been doing.

At AsterixDB we did Gerrit and has to do some tooling to make sure it
comply with ASF way.

- Henry

On Thu, Apr 14, 2016 at 11:07 AM, Wang, Yanping <ya...@intel.com>
wrote:

> I agree, we need a code review tools as well for Mnemonic. We are going to
> submit large patches. I include mnemonic dev list here for discussion.
>
> Thanks
>
> > On Apr 14, 2016, at 10:39 AM, Wes McKinney <we...@cloudera.com> wrote:
> >
> > hello all,
> >
> > We're reaching a junction where larger patches to the Arrow codebase
> > will become more frequent, and effective code reviews will be
> > important part of maintaining a high quality project going forward.
> >
> > In general, the GitHub pull request UI is not generally thought of as
> > very productive in large code reviews (some recent exposition on this
> > topic:
> http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/
> ).
> > Many large engineering teams prefer such (git-centric) tools as
> > Gerrit, though there are other code review tools available.
> >
> > I don't think we are at a point where a particular code review process
> > should be enforced, but more that we should have more tools available
> > for groups of Arrow committers who wish to collaborate in a particular
> > way.
> >
> > As I'm familiar with Gerrit from working on Apache projects that
> > Cloudera's involved with, my bias would be to try to get an instance
> > set up so that larger patches can be reviewed in a more detailed and
> > transactional way. For example: we could use gerrit.cloudera.org (like
> > Kudu and Impala), but I would be happy to use any infrastructure
> > provider.
> >
> > There has been some resistance / inaction within the ASF to create an
> > ASF-managed Gerrit instance:
> > https://issues.apache.org/jira/browse/INFRA-2205.
> >
> > I'm interested to hear other perspectives.
> >
> > Thanks,
> > Wes
>

Re: Code review tools for Arrow patches

Posted by Henry Saputra <he...@gmail.com>.
How about using Github Pull Requests as mechanism to do review?

So, all patches need to be done via Github mirror PRs, similar to Flink and
Spark and other new projects have been doing.

At AsterixDB we did Gerrit and has to do some tooling to make sure it
comply with ASF way.

- Henry

On Thu, Apr 14, 2016 at 11:07 AM, Wang, Yanping <ya...@intel.com>
wrote:

> I agree, we need a code review tools as well for Mnemonic. We are going to
> submit large patches. I include mnemonic dev list here for discussion.
>
> Thanks
>
> > On Apr 14, 2016, at 10:39 AM, Wes McKinney <we...@cloudera.com> wrote:
> >
> > hello all,
> >
> > We're reaching a junction where larger patches to the Arrow codebase
> > will become more frequent, and effective code reviews will be
> > important part of maintaining a high quality project going forward.
> >
> > In general, the GitHub pull request UI is not generally thought of as
> > very productive in large code reviews (some recent exposition on this
> > topic:
> http://www.beepsend.com/2016/04/05/abandoning-gitflow-github-favour-gerrit/
> ).
> > Many large engineering teams prefer such (git-centric) tools as
> > Gerrit, though there are other code review tools available.
> >
> > I don't think we are at a point where a particular code review process
> > should be enforced, but more that we should have more tools available
> > for groups of Arrow committers who wish to collaborate in a particular
> > way.
> >
> > As I'm familiar with Gerrit from working on Apache projects that
> > Cloudera's involved with, my bias would be to try to get an instance
> > set up so that larger patches can be reviewed in a more detailed and
> > transactional way. For example: we could use gerrit.cloudera.org (like
> > Kudu and Impala), but I would be happy to use any infrastructure
> > provider.
> >
> > There has been some resistance / inaction within the ASF to create an
> > ASF-managed Gerrit instance:
> > https://issues.apache.org/jira/browse/INFRA-2205.
> >
> > I'm interested to hear other perspectives.
> >
> > Thanks,
> > Wes
>