Provide testing installations for code review tools

[zooey]

Haiku is in need of a code review infrastructure.

In order to let developers/contributors evaluate the different tools available, it would be best to provide test installations.

Here's a (possibly incomplete) list of the potential candidates:

• gerrit
• gitlab
• phabricator

I had started to look into providing those by means of docker images, but that turned out to be somewhat more complicated than I expected. In order to avoid having to install and run docker on baron, I have set up docker on my own server, but so far have only managed to get an instance of phabricator running. Additional docker images for gerrit and gitlab would be nice. Once we have working images for those, I could host them on my server for evaluation purposes (if needed).

[richienyhus]

I could host a demo instance of a few of the code review tools on Google cloud via Bitnami if there is interest.

Tools on Bitnami so far: ​https://bitnami.com/stack/reviewboard ​https://bitnami.com/stack/gitlab ​https://bitnami.com/stack/gitorious

[waddlesplash]

I looked at it, but I think Phabricator is better than that...

Personally, my own take (and some feedback from others) so far:

• Gerrit is nice, but wants too much control over the Git repo for our liking
• GitLab wants to be a full replacement for cgit as well, I don't know if it can handle our 50K tags though
• Phabricator is nice because it's compartmentalized, so we can install the code review portion of Phabricator without installing the issue tracker and repository browser (LLVM does this I think?) But I'm not very fond of the UI...

[zooey]

Replying to richienyhus:

I could host a demo instance of a few of the code review tools on Google cloud via Bitnami if there is interest.

Tools on Bitnami so far: ​https://bitnami.com/stack/reviewboard ​https://bitnami.com/stack/gitlab ​https://bitnami.com/stack/gitorious

Good idea, that should be good enough for evaluation purposes, I hope.

[zooey]

Replying to waddlesplash:

I looked at it, but I think Phabricator is better than that...

Personally, my own take (and some feedback from others) so far:

• Gerrit is nice, but wants too much control over the Git repo for our liking
• GitLab wants to be a full replacement for cgit as well, I don't know if it can handle our 50K tags though
• Phabricator is nice because it's compartmentalized, so we can install the code review portion of Phabricator without installing the issue tracker and repository browser (LLVM does this I think?) But I'm not very fond of the UI...

Hm, what's the difference between Gerrit, Gitlab and Phabricator with respect to git? I thought they all were acting as git servers, so they kind of own the repository?

[waddlesplash]

Phabricator (the code review portion of it anyway) can be used without making it the "manager" of the Git repo IIRC. GitLab and Gerrit both want 100% control over the repo with no patches entering it from anywhere else.

[pulkomandy]

Is that a problem? Gerrit still allows pushing directly to the "main" repo, bypassing the code review process. I suspect gitlab is similar (I heard its workflow is similar to github?). The fact that they proxy the actual git repo is not really relevant to the workflow, as long as there is some way to push commits without having to go through the review process.

There may be sysadmin-related reasons to not want this (maybe it would make git checkouts slower, or whatever), but that's the point of reviewing the tools.

Here is a first try at a checklist:

• Must allow direct commits to the repo, bypassing code review process
• Must allow pushing code for review from the command line
• Must allow easily checking out changes for local testing and review
• Web interface must work in Haiku (either Web+, Qupzilla or NetSurf)
• Must scale to our repo and especially the unusual number of git tags

• Should integrate with buildbot to check that changes submitted don't break the build (and pass the test, when we run them in buildbot)
• Should integrate a code style checker
• Should rebase changes on trunk when they are accepted, not produce merge commits as github/bitbucket does
• Should allow easy review of both the changes, and the commit metadata (commit messages, multiple commits, etc)
• Should allow inline comments for code review
• Should allow managing multiple branches (release + trunk) and ideally multiple repositories (haiku + buildtools)

[richienyhus]

Does the code review tool need to be for both pre- and post-commit or is it OK if it is pre-commit only?

---

Here is an updated list of tools:

Open Source:

• Gerrit (Java EE)
• Rietveld (Python & Django)
• Review Board CE (Python)
• Differential aka Phabricator (PHP)
• Kallithea (Python)
• Barkeep (Ruby)
• Crew (PHP)
• Codebrag CE (Scala, JavaScript & Python)
• Gitlab CE (Ruby)
• Gitorious (Ruby)

Proprietary but free for OSS:

• Jetbeans UpSource
• Perforce Swarm
• Atlassian Crucible (includes sourcecode but not oss)
• Atlassian Stash (includes sourcecode but not oss)

[zooey]

Replying to pulkomandy:

Here is a first try at a checklist:

Nice! [ ... ]

• Should integrate with buildbot to check that changes submitted don't break the build (and pass the test, when we run them in buildbot)

I would make buildbot integration a hard requirement. While the tool doesn't have to support buildbot out-of-the-box, the tool must provide general support for integrating an external CI tool into the process (such that we just have to fill out some code template in order to get it to work with buildbot).

[zooey]

Replying to richienyhus:

Does the code review tool need to be for both pre- and post-commit or is it OK if it is pre-commit only?

I think the main focus is on pre-merge (i.e. collect commits somewhere before) review - post-merge review currently happens on the haiku-commits list and I guess it will continue to do so.

---

Here is an updated list of tools:

Thanks for compiling this, some comments from my POV:

Open Source:

• Gerrit (Java EE)

Has direct support from buildbot, should definitely be tried

• Rietveld (Python & Django)

Is what Gerrit is based on, but I don't think much is happening there anymore.

• Review Board CE (Python)

Does not seem to support continuous integration hooks.

• Differential aka Phabricator (PHP)

Does not seem to support continuous integration hooks (only as alpha subproject).

• Kallithea (Python)

Does not seem to support continuous integration hooks.

• Barkeep (Ruby)

Seems to be rather dead and does not seem to support continuous integration hooks.

• Crew (PHP)

Does not seem to support continuous integration hooks.

• Codebrag CE (Scala, JavaScript & Python)

Does not seem to support continuous integration hooks.

• Gitlab CE (Ruby)

Has direct support from buildbot, should definitely be tried.

• Gitorious (Ruby)

Doesn't seem to be able to handle our load of tags (definitely not the hosted version, which I have tried just today)

Proprietary but free for OSS:

• Jetbeans UpSource
• Perforce Swarm

Has an API that could be used to integrate buildbot, should probably be tried.

• Atlassian Crucible (includes sourcecode but not oss)
• Atlassian Stash (includes sourcecode but not oss)

Has an API that could be used to integrate buildbot, should probably be tried.

[richienyhus]

• Review Board CE (Python)

Does not seem to support continuous integration hooks.

This is meant to be handled by ReviewBot. Source comments says this is in beta, but the documentation says it is still in alpha: ​https://github.com/reviewboard/ReviewBot/blob/master/bot/reviewbot/tools/buildbot.py

• Kallithea (Python)

Does not seem to support continuous integration hooks.

Kallithea is a opensource version of RhodeCode Which has buildbot support. Kallithea still needs to replace that proprietary plugin with an opensource one. There is a Jenkins plugin on github, but there doesn't seem to be an open source buildbot plugin yet: ​https://github.com/moparisthebest/kallithea-hooks

• Codebrag CE (Scala, JavaScript & Python)

Does not seem to support continuous integration hooks.

There is an open pull request that should allow it to support continuous integration hooks, but that means code is not even alpha yet.

• Gitorious (Ruby)

Doesn't seem to be able to handle our load of tags (definitely not the hosted version, which I have tried just today)

Here is a link to a VM image of a 64bit version of Ubuntu pre-configured to run Gitorious: ​https://bitnami.com/stack/gitorious/virtual-machine

[waddlesplash]

Gitorious is something we really want to avoid IMO. It's really, really slow for doing just about anything at all, even without 50,000 tags.

[waddlesplash]

Gerrit is now live.