[RFC] switch to Gerrit

[Han-Wen Nienhuys]

n the spirit for providing competing options, I hereby offer a Gerrit
RFC. Note that I'm an obvious fan of Gerrit, but Gitlab seems an
acceptable solution to me too.


[RFC] Gerrit for LilyPond

Right now, LilyPond's source code is hosted on Savannah [1], our issues
are tracked on SourceForge [2] and we review patches on Rietveld [3].
There is no synchronization between the systems and a contributor is
required to synchronize the review and the associated issue.

I propose to start using self-hosted Gerrit for doing code
reviews and code review status tracking. Gerrit has integrated Git
hosting, and integrated code viewing


Sketch of processs
==================

In Gerrit, each commit is a reviewable unit. This means you send
several (stacked) commits for review in parallel, without needing to
submit them separately.

Gerrit has configurable voting labels. We could add several labels to
express the current status, eg.

  Code-Review (what we have today)
  Verified (tests pass)
  Regtest (visual inspection of regtests is OK)

For code review, we could appoint a group of core contributors
(maintainers) that can vote +2, so we could make a distinction between
reviews by passers-by and knowledgeable people. We can decide by
separate process who gets to vote +2; if we don't want this, we can
make everyone a maintainer for now.

Voting labels are also used to express nuance more clearly, eg. "looks
good, but someone else must decide" (+1) , "needs more work" (-1),
"veto" (-2).

We could give the patch meister the sole permission to click the
submit, so current process is rigorously enforced.

Since Gerrit has a dashboard that can filter by status and label, we
don't need a bugtracker for tracking patch process anymore. The
patchmeister can search for bugs with {Code-Review:+2, Verified:+1}.

Since Gerrit serves the git repo, the merging happens by directly
clicking a button.

Gerrit includes an (optional) code browser.

Each review has a destination branch; we can target our reviews to
staging, and continue using patchy for advancing master. In the long
run, we can improve our CI such that tested and approved patches go to
master directly.


Advantages
==========

The review experience of Gerrit is more refined than github/gitlab. It
is easy to work with multiple stacked changes, and one can easily
compare different versions of changes.

Gerrit is fully open source (Apache 2 licensed). While Google sponsors
most development, it is an established product for enterprise
deployments (SAP, Volvo, Qualcomm, Cloudera etc. all use Gerrit; it's
also the default solution for Android partners). It has a community
of developers outside Google, and even companies offering services
(eg. gerritforge, which runs review.gerrithub.io).

Gerrit is an open source tool, and is relatively easy to deploy; it is
run as a single Java process file on a single server. It does not have
its own authentication management, so it relies on account providers
(OpenID, OAuth with Facebook/Google/Github) instead.

Gerrit offers full takeout of review data through git. See here


https://gerrit.googlesource.com/gerrit/+/refs/changes/15/252615/meta%5E%21/#F1

for the data behind

  https://gerrit-review.googlesource.com/c/gerrit/+/252615


Disadvantages
=============

The workflow (which uses git rebase and git commit --amend) requires
more fluency with Git than GH/GL, and will create an additional
barrier to new contributors.

Gerrit lacks an issue tracker or integrated CI solution

Gerrit lacks "community" features, such as Wiki, @mentions, etc.

Gerrit as hosted by GerritForge requires a GitHub account. If this is
an issue, I volunteer to manage a self-hosted Gerrit instance.


Summary
=======

We can replace review/submission management/hosting with Gerrit,
getting a better review experience.

Compared to GL, it will be easier manage takeout and self-host, and is
a better solution if we desparately care about service-continuity.

Compared to GL, it has a higher bar of entry, because it requires more
Git fluency, and is less integrated with other tools.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen