You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Wes McKinney <we...@gmail.com> on 2016/06/09 20:45:17 UTC
Re: Code review tools for Arrow patches
hi folks,
Following up on this. My suggestion for a workflow to help with large
code reviews for Arrow is:
1) We set up an Arrow project on gerrit.cloudera.org. I'm hoping we
see gerrit.apache.org someday.
2) For reviews needing more careful scrutiny, code reviewer can
request to conduct the CR on Gerrit
3) Contributor will push change sets to Gerrit
4) [The slightly awkward part] In parallel, contributor will open a PR
on GitHub for purposes of trigging Travis CI verification
5) Arrow committer may cherry-pick verified commits to master and push
to ASF git repo
My understanding (someone more experienced should chime in) is that
Gerrit reviews are all made relative to the parent commit for a
particular change set. Thus, we may not need to worry (for now) about
synchronization issues between Gerrit and GitHub / ASF git.
Does this make sense? Any other ideas / thoughts welcome
Thanks,
Wes
On Mon, May 23, 2016 at 3:55 PM, Hanifi GUNES <ha...@gmail.com> wrote:
> I worked with Gerrit and GH both. My personal preference would be in favor
> of Gerrit because of its power user ready-ness and tight integration with
> git + git cli. Afaics there are legitimate concerns around possible
> trickiness of novice users' interaction with Gerrit. Not sure if this was
> mentioned above but there seems a Gerrit + GH plugin that mirrors GH
> pull-requests to Gerrit changes. Never used it but still this may be of
> help.
>
>
> 1: https://gerrit.googlesource.com/plugins/github/+/master/README.md
>
> 2016-05-13 8:47 GMT-07:00 Jason Altekruse <ja...@dremio.com>:
>
>> If everyone else would prefer Gerrit, I would be okay with using it
>> exclusively to simplify things. It does have several nice features beyond
>> reviewboard as it manages its own git repository, rather than just patch
>> files.
>>
>> Jason Altekruse
>> Software Engineer at Dremio
>> Apache Drill Committer
>>
>> On Thu, May 12, 2016 at 10:03 PM, Wes McKinney <we...@gmail.com>
>> wrote:
>>
>> > Apparently it is possible, but quite a lot of work:
>> >
>> > https://github.com/andygrunwald/gotrap
>> >
>> > The ideal thing, it would seem, would be to have the Gerrit code
>> > reviews with automatic replication of updated patch sets to a pull
>> > request (i.e. each new patch set force pushes the branch). I don't
>> > think we're going to get that, so I'm not sure how to proceed. The
>> > Kudu team uses Gerrit + Jenkins trigger (e.g. see it in action here
>> > http://gerrit.cloudera.org:8080/#/c/2992/)
>> >
>> > - Wes
>> >
>> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <em...@gmail.com>
>> > wrote:
>> > > Does gerrit work well with TravisCI, or will we need to develop/setup
>> > > another continuous integration solution?
>> > >
>> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
>> > > <da...@gmail.com> wrote:
>> > >> Admittedly, coming from the complete opposite end of the commit-size
>> > spectrum, the JIRA issue + GitHub pull request workflow already feels a
>> > little frictional for simple bugfixes and additions, so I was wary of
>> > Gerrit. But it actually looks pretty well-suited to small commits.
>> > >> One advantage I'd see to different platforms, though, would be the
>> > potential for JIRA integration. GitHub seems to have a more built-in
>> > solution for this, if it's something you could foresee setting up. But
>> > there seem to be ways to do it with Gerrit too.
>> > >> Clearly having an option to use GitHub pull requests lowers the
>> > barriers to entry for contributors, but I understand easy pull requests
>> are
>> > a double-edged sword for maintainers!
>> > >>
>> > >>
>> > >>
>> > >> _____________________________
>> > >> From: Wes McKinney <we...@gmail.com>
>> > >> Sent: Thursday, May 5, 2016 12:46 AM
>> > >> Subject: Re: Code review tools for Arrow patches
>> > >> To: <de...@arrow.apache.org>
>> > >>
>> > >>
>> > >> I'm also on board with this if it doesn't deter new contributors (it's
>> > >> a bit of additional process over GitHub but overall not too hard to
>> > >> learn).
>> > >>
>> > >> On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau <ja...@apache.org>
>> > wrote:
>> > >>> I dont know about the other pmc members and committers but I prefer
>> > just
>> > >>> making Gerrit the only way to submit patches rather than one of many.
>> > It
>> > >>> seems to work well for Asterix and Kudu.
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>>
Re: Code review tools for Arrow patches
Posted by Wes McKinney <we...@gmail.com>.
For me, at least, it's a time constraint. It should be possible to
replicate our current setup on Jenkins -- it would be useful to
continue to run Travis CI, but perhaps the builds can share common
shell scripts.
On Sat, Jun 11, 2016 at 12:56 PM, Jacques Nadeau <ja...@apache.org> wrote:
> Is the challenge with jenkins + gerrit a time constraint or a systems
> constraint? If the former, we can probably have other people collaborate to
> accomplish this. (If I understand what you said.)
>
>
> On Fri, Jun 10, 2016 at 3:41 PM, Wes McKinney <we...@gmail.com> wrote:
>
>> I am not sure how to do this while continuing to use Travis CI. I am
>> not able to set up a new CI environment (e.g. Jenkins + gerrit a la
>> Kudu) right now.
>>
>> I am having a hard time keeping track of the state of code reviews, so
>> I've proposed this triage solution (which will involve an extra force
>> push to get a green build) to assist with large reviews until we
>> achieve a more sustainable / streamlined solution (Jenkins + gerrit
>> replication, maybe someday).
>>
>> - Wes
>>
>> On Thu, Jun 9, 2016 at 7:53 PM, Jacques Nadeau <ja...@apache.org> wrote:
>> > I'm +1 if we remove step 4 and integrate testing into gerrit instead
>> >
>> > On Thu, Jun 9, 2016 at 1:45 PM, Wes McKinney <we...@gmail.com>
>> wrote:
>> >
>> >> hi folks,
>> >>
>> >> Following up on this. My suggestion for a workflow to help with large
>> >> code reviews for Arrow is:
>> >>
>> >> 1) We set up an Arrow project on gerrit.cloudera.org. I'm hoping we
>> >> see gerrit.apache.org someday.
>> >>
>> >> 2) For reviews needing more careful scrutiny, code reviewer can
>> >> request to conduct the CR on Gerrit
>> >>
>> >> 3) Contributor will push change sets to Gerrit
>> >>
>> >> 4) [The slightly awkward part] In parallel, contributor will open a PR
>> >> on GitHub for purposes of trigging Travis CI verification
>> >>
>> >> 5) Arrow committer may cherry-pick verified commits to master and push
>> >> to ASF git repo
>> >>
>> >> My understanding (someone more experienced should chime in) is that
>> >> Gerrit reviews are all made relative to the parent commit for a
>> >> particular change set. Thus, we may not need to worry (for now) about
>> >> synchronization issues between Gerrit and GitHub / ASF git.
>> >>
>> >> Does this make sense? Any other ideas / thoughts welcome
>> >>
>> >> Thanks,
>> >> Wes
>> >>
>> >> On Mon, May 23, 2016 at 3:55 PM, Hanifi GUNES <ha...@gmail.com>
>> >> wrote:
>> >> > I worked with Gerrit and GH both. My personal preference would be in
>> >> favor
>> >> > of Gerrit because of its power user ready-ness and tight integration
>> with
>> >> > git + git cli. Afaics there are legitimate concerns around possible
>> >> > trickiness of novice users' interaction with Gerrit. Not sure if this
>> was
>> >> > mentioned above but there seems a Gerrit + GH plugin that mirrors GH
>> >> > pull-requests to Gerrit changes. Never used it but still this may be
>> of
>> >> > help.
>> >> >
>> >> >
>> >> > 1: https://gerrit.googlesource.com/plugins/github/+/master/README.md
>> >> >
>> >> > 2016-05-13 8:47 GMT-07:00 Jason Altekruse <ja...@dremio.com>:
>> >> >
>> >> >> If everyone else would prefer Gerrit, I would be okay with using it
>> >> >> exclusively to simplify things. It does have several nice features
>> >> beyond
>> >> >> reviewboard as it manages its own git repository, rather than just
>> patch
>> >> >> files.
>> >> >>
>> >> >> Jason Altekruse
>> >> >> Software Engineer at Dremio
>> >> >> Apache Drill Committer
>> >> >>
>> >> >> On Thu, May 12, 2016 at 10:03 PM, Wes McKinney <we...@gmail.com>
>> >> >> wrote:
>> >> >>
>> >> >> > Apparently it is possible, but quite a lot of work:
>> >> >> >
>> >> >> > https://github.com/andygrunwald/gotrap
>> >> >> >
>> >> >> > The ideal thing, it would seem, would be to have the Gerrit code
>> >> >> > reviews with automatic replication of updated patch sets to a pull
>> >> >> > request (i.e. each new patch set force pushes the branch). I don't
>> >> >> > think we're going to get that, so I'm not sure how to proceed. The
>> >> >> > Kudu team uses Gerrit + Jenkins trigger (e.g. see it in action here
>> >> >> > http://gerrit.cloudera.org:8080/#/c/2992/)
>> >> >> >
>> >> >> > - Wes
>> >> >> >
>> >> >> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <
>> >> emkornfield@gmail.com>
>> >> >> > wrote:
>> >> >> > > Does gerrit work well with TravisCI, or will we need to
>> >> develop/setup
>> >> >> > > another continuous integration solution?
>> >> >> > >
>> >> >> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
>> >> >> > > <da...@gmail.com> wrote:
>> >> >> > >> Admittedly, coming from the complete opposite end of the
>> >> commit-size
>> >> >> > spectrum, the JIRA issue + GitHub pull request workflow already
>> feels
>> >> a
>> >> >> > little frictional for simple bugfixes and additions, so I was wary
>> of
>> >> >> > Gerrit. But it actually looks pretty well-suited to small commits.
>> >> >> > >> One advantage I'd see to different platforms, though, would be
>> the
>> >> >> > potential for JIRA integration. GitHub seems to have a more
>> built-in
>> >> >> > solution for this, if it's something you could foresee setting up.
>> But
>> >> >> > there seem to be ways to do it with Gerrit too.
>> >> >> > >> Clearly having an option to use GitHub pull requests lowers the
>> >> >> > barriers to entry for contributors, but I understand easy pull
>> >> requests
>> >> >> are
>> >> >> > a double-edged sword for maintainers!
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> _____________________________
>> >> >> > >> From: Wes McKinney <we...@gmail.com>
>> >> >> > >> Sent: Thursday, May 5, 2016 12:46 AM
>> >> >> > >> Subject: Re: Code review tools for Arrow patches
>> >> >> > >> To: <de...@arrow.apache.org>
>> >> >> > >>
>> >> >> > >>
>> >> >> > >> I'm also on board with this if it doesn't deter new contributors
>> >> (it's
>> >> >> > >> a bit of additional process over GitHub but overall not too
>> hard to
>> >> >> > >> learn).
>> >> >> > >>
>> >> >> > >> On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau <
>> jacques@apache.org
>> >> >
>> >> >> > wrote:
>> >> >> > >>> I dont know about the other pmc members and committers but I
>> >> prefer
>> >> >> > just
>> >> >> > >>> making Gerrit the only way to submit patches rather than one of
>> >> many.
>> >> >> > It
>> >> >> > >>> seems to work well for Asterix and Kudu.
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> >
>> >> >>
>> >>
>>
Re: Code review tools for Arrow patches
Posted by Jacques Nadeau <ja...@apache.org>.
Is the challenge with jenkins + gerrit a time constraint or a systems
constraint? If the former, we can probably have other people collaborate to
accomplish this. (If I understand what you said.)
On Fri, Jun 10, 2016 at 3:41 PM, Wes McKinney <we...@gmail.com> wrote:
> I am not sure how to do this while continuing to use Travis CI. I am
> not able to set up a new CI environment (e.g. Jenkins + gerrit a la
> Kudu) right now.
>
> I am having a hard time keeping track of the state of code reviews, so
> I've proposed this triage solution (which will involve an extra force
> push to get a green build) to assist with large reviews until we
> achieve a more sustainable / streamlined solution (Jenkins + gerrit
> replication, maybe someday).
>
> - Wes
>
> On Thu, Jun 9, 2016 at 7:53 PM, Jacques Nadeau <ja...@apache.org> wrote:
> > I'm +1 if we remove step 4 and integrate testing into gerrit instead
> >
> > On Thu, Jun 9, 2016 at 1:45 PM, Wes McKinney <we...@gmail.com>
> wrote:
> >
> >> hi folks,
> >>
> >> Following up on this. My suggestion for a workflow to help with large
> >> code reviews for Arrow is:
> >>
> >> 1) We set up an Arrow project on gerrit.cloudera.org. I'm hoping we
> >> see gerrit.apache.org someday.
> >>
> >> 2) For reviews needing more careful scrutiny, code reviewer can
> >> request to conduct the CR on Gerrit
> >>
> >> 3) Contributor will push change sets to Gerrit
> >>
> >> 4) [The slightly awkward part] In parallel, contributor will open a PR
> >> on GitHub for purposes of trigging Travis CI verification
> >>
> >> 5) Arrow committer may cherry-pick verified commits to master and push
> >> to ASF git repo
> >>
> >> My understanding (someone more experienced should chime in) is that
> >> Gerrit reviews are all made relative to the parent commit for a
> >> particular change set. Thus, we may not need to worry (for now) about
> >> synchronization issues between Gerrit and GitHub / ASF git.
> >>
> >> Does this make sense? Any other ideas / thoughts welcome
> >>
> >> Thanks,
> >> Wes
> >>
> >> On Mon, May 23, 2016 at 3:55 PM, Hanifi GUNES <ha...@gmail.com>
> >> wrote:
> >> > I worked with Gerrit and GH both. My personal preference would be in
> >> favor
> >> > of Gerrit because of its power user ready-ness and tight integration
> with
> >> > git + git cli. Afaics there are legitimate concerns around possible
> >> > trickiness of novice users' interaction with Gerrit. Not sure if this
> was
> >> > mentioned above but there seems a Gerrit + GH plugin that mirrors GH
> >> > pull-requests to Gerrit changes. Never used it but still this may be
> of
> >> > help.
> >> >
> >> >
> >> > 1: https://gerrit.googlesource.com/plugins/github/+/master/README.md
> >> >
> >> > 2016-05-13 8:47 GMT-07:00 Jason Altekruse <ja...@dremio.com>:
> >> >
> >> >> If everyone else would prefer Gerrit, I would be okay with using it
> >> >> exclusively to simplify things. It does have several nice features
> >> beyond
> >> >> reviewboard as it manages its own git repository, rather than just
> patch
> >> >> files.
> >> >>
> >> >> Jason Altekruse
> >> >> Software Engineer at Dremio
> >> >> Apache Drill Committer
> >> >>
> >> >> On Thu, May 12, 2016 at 10:03 PM, Wes McKinney <we...@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > Apparently it is possible, but quite a lot of work:
> >> >> >
> >> >> > https://github.com/andygrunwald/gotrap
> >> >> >
> >> >> > The ideal thing, it would seem, would be to have the Gerrit code
> >> >> > reviews with automatic replication of updated patch sets to a pull
> >> >> > request (i.e. each new patch set force pushes the branch). I don't
> >> >> > think we're going to get that, so I'm not sure how to proceed. The
> >> >> > Kudu team uses Gerrit + Jenkins trigger (e.g. see it in action here
> >> >> > http://gerrit.cloudera.org:8080/#/c/2992/)
> >> >> >
> >> >> > - Wes
> >> >> >
> >> >> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <
> >> emkornfield@gmail.com>
> >> >> > wrote:
> >> >> > > Does gerrit work well with TravisCI, or will we need to
> >> develop/setup
> >> >> > > another continuous integration solution?
> >> >> > >
> >> >> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
> >> >> > > <da...@gmail.com> wrote:
> >> >> > >> Admittedly, coming from the complete opposite end of the
> >> commit-size
> >> >> > spectrum, the JIRA issue + GitHub pull request workflow already
> feels
> >> a
> >> >> > little frictional for simple bugfixes and additions, so I was wary
> of
> >> >> > Gerrit. But it actually looks pretty well-suited to small commits.
> >> >> > >> One advantage I'd see to different platforms, though, would be
> the
> >> >> > potential for JIRA integration. GitHub seems to have a more
> built-in
> >> >> > solution for this, if it's something you could foresee setting up.
> But
> >> >> > there seem to be ways to do it with Gerrit too.
> >> >> > >> Clearly having an option to use GitHub pull requests lowers the
> >> >> > barriers to entry for contributors, but I understand easy pull
> >> requests
> >> >> are
> >> >> > a double-edged sword for maintainers!
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >> _____________________________
> >> >> > >> From: Wes McKinney <we...@gmail.com>
> >> >> > >> Sent: Thursday, May 5, 2016 12:46 AM
> >> >> > >> Subject: Re: Code review tools for Arrow patches
> >> >> > >> To: <de...@arrow.apache.org>
> >> >> > >>
> >> >> > >>
> >> >> > >> I'm also on board with this if it doesn't deter new contributors
> >> (it's
> >> >> > >> a bit of additional process over GitHub but overall not too
> hard to
> >> >> > >> learn).
> >> >> > >>
> >> >> > >> On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau <
> jacques@apache.org
> >> >
> >> >> > wrote:
> >> >> > >>> I dont know about the other pmc members and committers but I
> >> prefer
> >> >> > just
> >> >> > >>> making Gerrit the only way to submit patches rather than one of
> >> many.
> >> >> > It
> >> >> > >>> seems to work well for Asterix and Kudu.
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> > >>
> >> >> >
> >> >>
> >>
>
Re: Code review tools for Arrow patches
Posted by Wes McKinney <we...@gmail.com>.
I am not sure how to do this while continuing to use Travis CI. I am
not able to set up a new CI environment (e.g. Jenkins + gerrit a la
Kudu) right now.
I am having a hard time keeping track of the state of code reviews, so
I've proposed this triage solution (which will involve an extra force
push to get a green build) to assist with large reviews until we
achieve a more sustainable / streamlined solution (Jenkins + gerrit
replication, maybe someday).
- Wes
On Thu, Jun 9, 2016 at 7:53 PM, Jacques Nadeau <ja...@apache.org> wrote:
> I'm +1 if we remove step 4 and integrate testing into gerrit instead
>
> On Thu, Jun 9, 2016 at 1:45 PM, Wes McKinney <we...@gmail.com> wrote:
>
>> hi folks,
>>
>> Following up on this. My suggestion for a workflow to help with large
>> code reviews for Arrow is:
>>
>> 1) We set up an Arrow project on gerrit.cloudera.org. I'm hoping we
>> see gerrit.apache.org someday.
>>
>> 2) For reviews needing more careful scrutiny, code reviewer can
>> request to conduct the CR on Gerrit
>>
>> 3) Contributor will push change sets to Gerrit
>>
>> 4) [The slightly awkward part] In parallel, contributor will open a PR
>> on GitHub for purposes of trigging Travis CI verification
>>
>> 5) Arrow committer may cherry-pick verified commits to master and push
>> to ASF git repo
>>
>> My understanding (someone more experienced should chime in) is that
>> Gerrit reviews are all made relative to the parent commit for a
>> particular change set. Thus, we may not need to worry (for now) about
>> synchronization issues between Gerrit and GitHub / ASF git.
>>
>> Does this make sense? Any other ideas / thoughts welcome
>>
>> Thanks,
>> Wes
>>
>> On Mon, May 23, 2016 at 3:55 PM, Hanifi GUNES <ha...@gmail.com>
>> wrote:
>> > I worked with Gerrit and GH both. My personal preference would be in
>> favor
>> > of Gerrit because of its power user ready-ness and tight integration with
>> > git + git cli. Afaics there are legitimate concerns around possible
>> > trickiness of novice users' interaction with Gerrit. Not sure if this was
>> > mentioned above but there seems a Gerrit + GH plugin that mirrors GH
>> > pull-requests to Gerrit changes. Never used it but still this may be of
>> > help.
>> >
>> >
>> > 1: https://gerrit.googlesource.com/plugins/github/+/master/README.md
>> >
>> > 2016-05-13 8:47 GMT-07:00 Jason Altekruse <ja...@dremio.com>:
>> >
>> >> If everyone else would prefer Gerrit, I would be okay with using it
>> >> exclusively to simplify things. It does have several nice features
>> beyond
>> >> reviewboard as it manages its own git repository, rather than just patch
>> >> files.
>> >>
>> >> Jason Altekruse
>> >> Software Engineer at Dremio
>> >> Apache Drill Committer
>> >>
>> >> On Thu, May 12, 2016 at 10:03 PM, Wes McKinney <we...@gmail.com>
>> >> wrote:
>> >>
>> >> > Apparently it is possible, but quite a lot of work:
>> >> >
>> >> > https://github.com/andygrunwald/gotrap
>> >> >
>> >> > The ideal thing, it would seem, would be to have the Gerrit code
>> >> > reviews with automatic replication of updated patch sets to a pull
>> >> > request (i.e. each new patch set force pushes the branch). I don't
>> >> > think we're going to get that, so I'm not sure how to proceed. The
>> >> > Kudu team uses Gerrit + Jenkins trigger (e.g. see it in action here
>> >> > http://gerrit.cloudera.org:8080/#/c/2992/)
>> >> >
>> >> > - Wes
>> >> >
>> >> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <
>> emkornfield@gmail.com>
>> >> > wrote:
>> >> > > Does gerrit work well with TravisCI, or will we need to
>> develop/setup
>> >> > > another continuous integration solution?
>> >> > >
>> >> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
>> >> > > <da...@gmail.com> wrote:
>> >> > >> Admittedly, coming from the complete opposite end of the
>> commit-size
>> >> > spectrum, the JIRA issue + GitHub pull request workflow already feels
>> a
>> >> > little frictional for simple bugfixes and additions, so I was wary of
>> >> > Gerrit. But it actually looks pretty well-suited to small commits.
>> >> > >> One advantage I'd see to different platforms, though, would be the
>> >> > potential for JIRA integration. GitHub seems to have a more built-in
>> >> > solution for this, if it's something you could foresee setting up. But
>> >> > there seem to be ways to do it with Gerrit too.
>> >> > >> Clearly having an option to use GitHub pull requests lowers the
>> >> > barriers to entry for contributors, but I understand easy pull
>> requests
>> >> are
>> >> > a double-edged sword for maintainers!
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> _____________________________
>> >> > >> From: Wes McKinney <we...@gmail.com>
>> >> > >> Sent: Thursday, May 5, 2016 12:46 AM
>> >> > >> Subject: Re: Code review tools for Arrow patches
>> >> > >> To: <de...@arrow.apache.org>
>> >> > >>
>> >> > >>
>> >> > >> I'm also on board with this if it doesn't deter new contributors
>> (it's
>> >> > >> a bit of additional process over GitHub but overall not too hard to
>> >> > >> learn).
>> >> > >>
>> >> > >> On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau <jacques@apache.org
>> >
>> >> > wrote:
>> >> > >>> I dont know about the other pmc members and committers but I
>> prefer
>> >> > just
>> >> > >>> making Gerrit the only way to submit patches rather than one of
>> many.
>> >> > It
>> >> > >>> seems to work well for Asterix and Kudu.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> >
>> >>
>>
Re: Code review tools for Arrow patches
Posted by Jacques Nadeau <ja...@apache.org>.
I'm +1 if we remove step 4 and integrate testing into gerrit instead
On Thu, Jun 9, 2016 at 1:45 PM, Wes McKinney <we...@gmail.com> wrote:
> hi folks,
>
> Following up on this. My suggestion for a workflow to help with large
> code reviews for Arrow is:
>
> 1) We set up an Arrow project on gerrit.cloudera.org. I'm hoping we
> see gerrit.apache.org someday.
>
> 2) For reviews needing more careful scrutiny, code reviewer can
> request to conduct the CR on Gerrit
>
> 3) Contributor will push change sets to Gerrit
>
> 4) [The slightly awkward part] In parallel, contributor will open a PR
> on GitHub for purposes of trigging Travis CI verification
>
> 5) Arrow committer may cherry-pick verified commits to master and push
> to ASF git repo
>
> My understanding (someone more experienced should chime in) is that
> Gerrit reviews are all made relative to the parent commit for a
> particular change set. Thus, we may not need to worry (for now) about
> synchronization issues between Gerrit and GitHub / ASF git.
>
> Does this make sense? Any other ideas / thoughts welcome
>
> Thanks,
> Wes
>
> On Mon, May 23, 2016 at 3:55 PM, Hanifi GUNES <ha...@gmail.com>
> wrote:
> > I worked with Gerrit and GH both. My personal preference would be in
> favor
> > of Gerrit because of its power user ready-ness and tight integration with
> > git + git cli. Afaics there are legitimate concerns around possible
> > trickiness of novice users' interaction with Gerrit. Not sure if this was
> > mentioned above but there seems a Gerrit + GH plugin that mirrors GH
> > pull-requests to Gerrit changes. Never used it but still this may be of
> > help.
> >
> >
> > 1: https://gerrit.googlesource.com/plugins/github/+/master/README.md
> >
> > 2016-05-13 8:47 GMT-07:00 Jason Altekruse <ja...@dremio.com>:
> >
> >> If everyone else would prefer Gerrit, I would be okay with using it
> >> exclusively to simplify things. It does have several nice features
> beyond
> >> reviewboard as it manages its own git repository, rather than just patch
> >> files.
> >>
> >> Jason Altekruse
> >> Software Engineer at Dremio
> >> Apache Drill Committer
> >>
> >> On Thu, May 12, 2016 at 10:03 PM, Wes McKinney <we...@gmail.com>
> >> wrote:
> >>
> >> > Apparently it is possible, but quite a lot of work:
> >> >
> >> > https://github.com/andygrunwald/gotrap
> >> >
> >> > The ideal thing, it would seem, would be to have the Gerrit code
> >> > reviews with automatic replication of updated patch sets to a pull
> >> > request (i.e. each new patch set force pushes the branch). I don't
> >> > think we're going to get that, so I'm not sure how to proceed. The
> >> > Kudu team uses Gerrit + Jenkins trigger (e.g. see it in action here
> >> > http://gerrit.cloudera.org:8080/#/c/2992/)
> >> >
> >> > - Wes
> >> >
> >> > On Mon, May 9, 2016 at 4:48 PM, Micah Kornfield <
> emkornfield@gmail.com>
> >> > wrote:
> >> > > Does gerrit work well with TravisCI, or will we need to
> develop/setup
> >> > > another continuous integration solution?
> >> > >
> >> > > On Wed, May 4, 2016 at 10:08 PM, Daniel Robinson
> >> > > <da...@gmail.com> wrote:
> >> > >> Admittedly, coming from the complete opposite end of the
> commit-size
> >> > spectrum, the JIRA issue + GitHub pull request workflow already feels
> a
> >> > little frictional for simple bugfixes and additions, so I was wary of
> >> > Gerrit. But it actually looks pretty well-suited to small commits.
> >> > >> One advantage I'd see to different platforms, though, would be the
> >> > potential for JIRA integration. GitHub seems to have a more built-in
> >> > solution for this, if it's something you could foresee setting up. But
> >> > there seem to be ways to do it with Gerrit too.
> >> > >> Clearly having an option to use GitHub pull requests lowers the
> >> > barriers to entry for contributors, but I understand easy pull
> requests
> >> are
> >> > a double-edged sword for maintainers!
> >> > >>
> >> > >>
> >> > >>
> >> > >> _____________________________
> >> > >> From: Wes McKinney <we...@gmail.com>
> >> > >> Sent: Thursday, May 5, 2016 12:46 AM
> >> > >> Subject: Re: Code review tools for Arrow patches
> >> > >> To: <de...@arrow.apache.org>
> >> > >>
> >> > >>
> >> > >> I'm also on board with this if it doesn't deter new contributors
> (it's
> >> > >> a bit of additional process over GitHub but overall not too hard to
> >> > >> learn).
> >> > >>
> >> > >> On Tue, May 3, 2016 at 9:59 AM, Jacques Nadeau <jacques@apache.org
> >
> >> > wrote:
> >> > >>> I dont know about the other pmc members and committers but I
> prefer
> >> > just
> >> > >>> making Gerrit the only way to submit patches rather than one of
> many.
> >> > It
> >> > >>> seems to work well for Asterix and Kudu.
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> >
> >>
>