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 <wesmck...@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 <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. > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > > >> >> > >> >
