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

[Jan Kundrát]

On Monday, 4 February 2013 11:51:31 CEST, Ben Cooksley wrote:
> 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.

Personally, for me it is the other way round. With Gerrit, I simply add a single git remote, but with Reviewboard, I have to either keep generating patches (a manual step) or have to install a 3rd party package, remember its options (--guess-summary? --guess-description? Oh, and my changes are of course already commited, so that's yet another option).

Of course, I'm capable of scripting these steps and therefore I can achieve a reasonably efficient workflow when I'm the one sending reviews for a project. However, I'm a project maintainer as well and I want to *review* other people's patches. Using Gerrit, it's a simple git remote, something which I prefer over *anything* else. Using Reviewboard, I have to download files through my web browser, guess on top of which commit they apply (yes, this has been a problem for me), and then come up with a correct command to apply them (`git am`? `git apply`? `patch -p1`?). I'm trying to come up with something better because I got bitten by each of these steps (really).

> 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 share your worries about the integrity of the repositories. However, that does not mean that we cannot use Gerrit. In particular, I don't see any reason why Gerrit cannot be a user similar to any other one, i.e. the authoritative copy of each repo shall remain on a gitolite-managed machine and Gerrit shall act simply as another machine which can push into the repositories. We could even change the metadata which get added to commits ("pushed by jkt into branch master") into something which makes it clear that it was done via Gerrit ("pushed by jkt into branc hmaster via Gerrit") for proper auditing purposes.

That might be the root of the misunderstanding here -- I'm not proposing to let Gerrit be the gateway; I'm proposing setting it up as a standalone service for code review. Similarly to how the anongit mirros are updated, a push by an authorized user via gitolite shall trigger a direct push (via an appropriate service identity) to Gerrit. The docs I've read suggest that this can work just fine.

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

You're right, but Gerrit does not require any IDE support at all. The whole point of the integrtion is that it works at the level of a special git remote. User pushes into a "magic remote" and all of the interesting stuff happens outside of their box. Another remote head gets created which can then be used by anyone else to easily fetch the changes under review. No need to fiddle with an IDE, no need to install 3rd party tools, no need to switch to the web browser, no passing of files required.

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

Surely there is a trigger/hook/... which runs when you detect that a new repo got created, if only to sync it to the other mirrors, right? This trigger can be extended to configure gerrit properly. Would that be a problem?

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

Looks like this assumes that Gerrit is the primary place where to push. That's not what I'm proposing.

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

Agreed.

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

Agreed. I'll be happy to help if time permit.

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

Unless I'm very mistaken, these points no longer apply when Gerrit is not the primary repo.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/