Why not hosting this project on gerrit-review.googlesource.com?

[lucamilanesio]

Hi @uwolfer, I was wondering if it would make sense to have this project hosted on gerrit-review.googlesource.com and thus getting the reviews and audience of Gerrit devs and contributors :-)

What do you think?

Luca.

[uwolfer]

It would probably make sense to do that.

What changes would be required for doing that?

• Change package-name to com.google?
• Change copyright?
• What else?

[sschuberth]

One argument against hosting it on gerrit-review.googlesource.com is that we'd lose the nice TravisCI / Coveralls / VersionEye integrations.

[lucamilanesio]

@sschuberth let me answer:

• TravisCI => all Gerrit code is built on gerrit-ci.gerritforge.com
• Coveralls => we can run JaCoCo and integrate with Jenkins
• VersionEye => All Gerrit code is mirrored to GitHub anyway, we won't lose it

@uwolfer no need to change package-name or copyright

[sschuberth]

@lucamilanesio, sure that's doable, but it creates work with unclear benefit, while the current setup just works. VersionEye, howvever, has shut down anyway.

[lucamilanesio]

@sschuberth Code Reviews? Discoverability? Integration and alignment with Gerrit Builds? Those sound to me clear benefits :-)

[sschuberth]

It's not that there are no code reviews at all at GitHub 😉 Your other points might be benefits depending on whether you get existing contributors to also sign up on gerrit-review.

But for me the real downside of using gerrit-review is the complicated CI setup. I once tried to get pre-submit checks running for reviewit and gave up. Too much copying of awkwardly interconnected jenkins-job-builder files in a separate repo vs. a single .travis.yml file inside the gerrit-rest-java-client repo.

[lucamilanesio]

@sschuberth if you are contributing to this plugin, I assume you know how to use Gerrit, isn't it? With regards to the complicated CI setup ... are you sure? There is a gerrit-ci-scripts repo on gerrit-review and you just need to create a YAML file, even simpler than the Travis one. That doesn't sound complicated at all IMHO.

[sschuberth]

It's not about knowing how to use Gerrit, it's about being willing to create an account on the gerrit-review instance. That's what I meant.

WRT to adding pre-submit checks that give Verify+1 feedback (not post-submit checks for master), I can give that a try for reviewit again. Maybe things have changed and it's easier now.

[lucamilanesio]

@sschuberth I see your point. Another alternative could be using review.gerrithub.io which can import pull-requests and uses the same GitHub accounts.

I remember the reviewit story and things are getting much easier: I am about to release today a brand-new Jenkins plugin that I have announced back in August.

[lucamilanesio]

@sschuberth a value on being on gerrit-review is the ability to get more contributions and inputs from the community of the Gerrit maintainers and contributors (see Gerrit Analytics for a list of the past 12 months contributors). Additionally, this project would become part of the GerritCodeReview GitHub organization, which would give it an official endorsement.

[sschuberth]

We were looking at gerrithub, too, but one of its downsides it that there's not automatic bidirectional sync between incremental comments on GitHub and Gerrit (which, granted, is hard to do).

Looking forward to your Jenkins plugin, though! Is this going to replace the jenkins-job-builder based setup on gerrit-review?

[lucamilanesio]

@sschuberth yes, the new plugin is going to replace the jenkins-job-builder mechanism. Since the introduction of the Jenkinsfile, there is no need anymore to generate tons of jobs automatically through scripting.

In a nutshell, a "Gerrit-powered Job" will automatically see the changes in the "Pull request" tab and you'll be able to send feedback to Gerrit from the Jenkinsfile, without having to rely on complex Groovy scripting or on the Gerrit Trigger plugin conf.

[lucamilanesio]

@uwolfer @sschuberth we are now using the new Gerrit Code Review plugin for Jenkins on gerrit-review and projects can have a Jenkinsfile and have their changes automatically verified.

Is this potentially the right moment to move the project over? P.S. All the projects on gerrit-review are mirrored to GitHub anyway, under the 'GerritCodeReview' organisation.