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
