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

[Ben Cooksley]

On Fri, Feb 1, 2013 at 6:18 AM, Thomas Koch <thomas at koch.ro> wrote:
> Hi Jan,

Hi Thomas,

>
> 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:

Does this include the user interface? The parts I have seen of it are
not user friendly at all...

>
> 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 ...).

That is a very complex process, and does not compare to the workflow
necessary for KDE.

I suspect that Gerrit would complicate our existing process and
introduce barriers to entry. This is particularly concerning because
some existing developers already have problems with Git itself, and I
fear Gerrit would simply complicate this process even further.

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

The integrity of the master Git repositories can never be called into
question. The impact upon the community of the master repositories
being unavailable would be quite disruptive I suspect. A public facing
web server is less secure and could be subject to compromise far
easier than our existing system.

I doubt any one person has at any point in time a full and complete
backup of all repositories from which a restore could be made
(considering we have 523 repositories).  The copies stored throughout
our infrastructure are generally updated very often, so they cannot be
used as a backup.

>
>> 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)

I doubt a majority of KDE Developers use Eclipse. Applications such as
KDevelop and Qt Creator would be more more likely candidates.

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

A few extra comments:

- From what I see Gerrit requires that an administrator register all
new repositories, which is incompatible with our approach of allowing
developers to create scratch repositories freely, as well as clones of
mainline repositories.

- We would also have to configure each newly created repository
explicitly to permit direct pushes assuming it supports that (not
permitting direct pushes is unacceptable). This level of access would
have to be restricted to KDE Developers as well, and not allowed to
anyone who had simply registered on the instance.

- An API or CLI interface for the above would be mandatory for
scripting, as otherwise errors may be introduced into the repository
setup due to the large number of repositories we have. The interface
must be able to accept fully populated commands without prompting
(unless it is for confirmation / acceptance ).

- Currently Identity is responsible for SSH key management, and those
keys are used not only by git.kde.org but by others such as
svn.kde.org as well. This repository of keys is accessed frequently by
sysadmins when granting individuals access to other aspects of our
infrastructure. Therefore we would have to customise Gerrit to use the
Identity / LDAP data store instead.

- KDE will need to continue to keep Subversion alive for translators
indefinitely at this point. Our current migration path involves using
functionality
built into Gitolite which permits one to pass-through Subversion
requests. A migration to Gerrit would kill this path - requiring the
maintenance of a separate system (with SSH keys, accounts, etc to
match - which Gitolite would have looked after for us).

- It would very likely require (potentially invasive) changes to our
current anongit system, and likely our existing Git hooks to a certain
extent as well.

>
> Regards,

Regards,
Ben Cooksley
KDE Sysadmin

>
> Thomas Koch, http://www.koch.ro
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest