Re: [RFC] switch to Gerrit

[Jonas Hahnfeld]

Am Freitag, den 07.02.2020, 12:09 +0100 schrieb 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.

Thanks for writing this up! Even if I said I didn't like Gerrit in the
past, I would certainly find my way to use it should we agree on it as
a tool. And it looks like the tool has improved a lot since I last
tried to understand it.

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

Hm, a presentation by Google itself claims that "Gerrit does not
provide [...] Code Browsing, Code Search" [1] If I look on GerritHub,
it has links to GitHub [2] and that's something we don't want to use as
far as I understand.

1: 
https://docs.google.com/presentation/d/1C73UgQdzZDw0gzpaEqIC6SPujZJhqamyqO1XOHjH-uk/edit#slide=id.g4d6c16487b_1_140
2: https://review.gerrithub.io/admin/repos/q/filter:lilypond


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

(probably the later for now, to keep the proposal focused and mostly
keep the current "process" on top of the tools)

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

Oh, so maybe that's a new feature? (see note above) Does this work on
GerritHub, can we see this in action somewhere?

> 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

That's pretty cool, but requires the server to be available. Does it
have offline backups / export?

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

Can't you request review from somebody? That would probably be enough
to model the current workflow.

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

Jonas

signature.asc
Description: This is a digitally signed message part