[Kde-scm-interest] Integrating Reviewboard with git branches

[Thomas Koch]

Hi Jan,

I'm a big gerrit fanboy and have presented it on several occasions and I still 
have nightmares from using jira + reviewboard + git-svn when working on an 
Apache project.

I'm not involved in KDE but I'd love to see another big project realizing the 
beauty of gerrit. I've some comments inline:

Jan Kundrát:
> Hi,
> I'd like to start a discussion about integrating the reviews and git more
> tightly. In particular, what I dislike about the reviewboard is that as a
> project maintainer, I have to carry the patches by hand and that the web
> interface has no information about what the parent commit is.
I had the impression that the high cost of doing a change in Apache ZooKeeper 
was one reason for the bad code quality. Nobody wanted to start a costly patch 
process just to clean up a one liner although it would've been worth it.

In the case of Apache ZooKeeper that was: Opening a jira bug, exporting a 
patch file from git (or even svn), upload patch to jira, wait for jenkins, 
login to reviewboard, upload patch to reviewboard, fill out a few fields in 
reviewboard, (repeat if necessary ...).

> I have some experience (as a user) with the qt-project's Gerrint instance.
> As I understand the past discussions on this topic, the sysadmins were
> opposed to giving push access to a random public-facing web server; there
I don't understand what's the problem. Even in the worst case that somebody 
would screw up an official Git repo (how?): Every developer has a full backup 
and there's nothing easier then to make douzens of backups of a git repo.

> were also concerns about the ease of setup for the users (Gerrit ships
Do you know https://github.com/openstack-infra/git-review ?

> with its own SSH server implementation, so that means either a custom port
> to set by all developers or weird setup for the sysadmins). Finally, it
> looks that the KDE community is now happy with the Reviewboard and its UI.
Have you seen the eclipse integration of gerrit? You don't want to use the web 
interface anymore once you saw it.
http://koch.ro/temp/gerrit_skillsmatter.mp4 (minute 12)

> - The git branches shall be the authoritative source of data. I have seen
> reviews [1] where RB broke on patches containing binary data; the patches
> I downloaded from RB were different than what was sent to the RB and my
> git refused to apply them.
Same (horrible) experience with the Apache reviewboard.


> - The system will have to distinguish between an updated review request and
> a completely new one. In Qt-project's Gerrit, this is achieved by a
> `commit-msg` hook which adds a Change-Id header to the commit message;
> Gerrit denies pushes which don't contain this header. If a commit has
Gerrit can also be configured to create new reviews for commits without 
Change-Id AFAIR.

> - Another question is how to deal with pushes which consist of several
> commits -- shall we refuse them, i.e. require all changes squashed into a
> single commit? I don't know how the comparable systems work.
There are people working on "topic reviews" on the gerrit mailing list. But 
I'm not really sure whether it's worth the effort. I think of each commit as a 
standalone reviewable entity like a database transaction from one consistent 
state to the next.

> - It shall be probably noted that in a few years, a request for integrating
> the review system with automated continuous integration will surely arrive
> (if it doesn't arrive, I'll ask for that); we shall probably take this
> into account now.
The video above also nicely shows jenkins integration. I uploaded the video to 
my server to have it ready for gerrit presentations.

> And yes, I'm willing to help within the limited spare time and experience I
> have.
I'd also be interested to see KDE use gerrit and would like to see whether I 
could help.

Regards,

Thomas Koch, http://www.koch.ro