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 <jacq...@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 <wesmck...@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 <hanifigu...@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 <wesmck...@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 < >> emkornfi...@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 >> >> > > <danrobinson...@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 <wesmck...@gmail.com> >> >> > >> Sent: Thursday, May 5, 2016 12:46 AM >> >> > >> Subject: Re: Code review tools for Arrow patches >> >> > >> To: <dev@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 <jacq...@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. >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >>
