Sadly, not sure this is going to be possible without a lot of work. ;(

Issues/Hurdles:

• We currently run 0 java/tomcat apps, so there's no setup for it.

• None of the Fedora admins are up to speed on java/tomcat, so we would need to get someone involved who is or train existing admins to do so.

• We have been working on a similar tool called 'ReviewBoard'. It wasn't fully deployed to hosted yet, and we are looking and just having folks run it via openshift. Would this meet your needs? Either using ReviewBoard this way, or getting setup to run Gerrit this way?

• Gerrit is not currently packaged in EPEL, which we require for all tools we use.
  It looks like it might be difficult to package, as it bundles a ton of other items. ;(

Understood. I think packaging Gerrit for Fedora will be the first major hurdle. I have done some work on this already. I made progress on some of its smaller dependencies, but then I hit the major roadblock of GWT. Suffice to say its build process is very unfriendly towards actually building all the bits from source, which is of course mandatory for Fedora. However from speaking to the folks in #fedora-java there does seem to be wider interest in getting GWT packaged properly (for other apps), so this may happen eventually.

Running a Gerrit instance on OpenShift sounds like a good idea, I will look into this (even if only as a stopgap measure).

yeah, GWT is used by lots of things, but has proved to be difficult to package up. ;(

I'll go ahead and close this now, but do reopen if there is anything we can do from here.

Hello,
I did some Gerrit testing recently and I'd like to comment issues that have been stated couple comments above:
* Gerrit has its own daemon setup, no special Tomcat installation is needed whatsoever
* none Tomcat experience and only basic Java knowledge is needed
* I'm not sure about ReviewBoard but Gerrit directly works with git repositories, therefore integration with current Fedorahosted git repositories should be smooth

I'm not sure how crucial is the requirement that it has to be packaged for EPEL, but as for the maintenance of the installation itself, I'm willing to take care of that if there will be noone better.

I'm reopening this ticket.

There are a number of projects that are hosted at fedorahosted.org that are very interested in having a public Gerrit instance. The following projects would like to use Gerrit:

FreeIPA, 389 Directory Server, Dogtag Certificate System, SSSD

Gerrit would allow hosted projects to have a structured review process. In addition, it would allow hosted projects to integrate continuous integration builds and tests with the review process if projects leverage the integration between Gerrit and Jenkins. This is a huge benefit for projects.

Getting Gerrit up and running on current Fedora releases is very straight-forward. As mentioned in comment#4 above, it has it's own daemon, so Tomcat isn't required. I didn't encounter any other dependency issues. Gerrit also has OpenID integration, so it can easily leverage the Fedora Account System.

I also explored running Gerrit on OpenShift, and even got a partially working cartridge, but there are some big limitations due to the inability to expose Gerrit's ssh interface.

Is it possible to have a hosted Gerrit server? Is packaging for EPEL still a requirement (and the main blocker)?

I will take this ticket.

To first answer the last question: yes, packaging for RHEL (EPEL) is a hard requirement.
I am not aware of the current packaging state, but as soon as it is packaged, we can continue.

Do you have any idea about the memory requirements for gerrit, so we can get an idea for what kind of resources we need, if we would be going to deploy this?

Also, it supports OpenID, but does it also support the OpenID teams extension?
I would prefer that, as otherwise we have two sets of permissions to maintain (FAS and gerrit), which isn't going to work out very well.
(This is not an issue for ReviewBoard as there the groups are only for notifications.)
If you need any help on getting the teams extension in it, feel free to ask me any information you require.

Replying to [comment:6 puiterwijk]:

Do you have any idea about the memory requirements for gerrit, so we can get an idea for what kind of resources we need, if we would be going to deploy this?

I have not investigated the memory requirements. In terms of disk, it needs to contain the git repositories. Since there is both a pending and stable repository for each project, I would think that the space is doubled over a normal git repository for a given project. There is also a database used for review comments, so that will grow over time. I don't have any exact estimates, as it all depends on how many projects would use Gerrit in addition to the activity level of the projects.

Also, it supports OpenID, but does it also support the OpenID teams extension?
I would prefer that, as otherwise we have two sets of permissions to maintain (FAS and gerrit), which isn't going to work out very well.

I'm not sure, but I agree that it would be nice to leverage FAS for permissions if possible. I didn't see anything referring to OpenID extensions in the Gerrit documentation.

(This is not an issue for ReviewBoard as there the groups are only for notifications.)
If you need any help on getting the teams extension in it, feel free to ask me any information you require.

I will see if I can dig up any answers to your questions, though it sounds like packaging is the first hurdle to overcome.

Building Gerrit is starting to look prohibative. They ues Facebook Buck as a Build tool (not Maven) which has 95 embedded Jar files in it: getting Buck to actually work in a Fedora pure environment is going to be painful with little to show for it.

It might be possible to build an unclean Binary version of buck and then use that to build gerrit.

Gerrit at least does not ship with Jar files embedded in its Git repo. It might be possible to build gerrit using Maven instead of Buck, which would then make a Fedora Clean deployment possible.