[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+Yezqn1JZac9=R1dmgZ4d6N1btAsP6AHON-Cds1knTaiA@mail.gmail.com>
Date: Wed, 26 Feb 2020 09:28:29 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Cc: Han-Wen Nienhuys <hanwen@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
Ben Gardon <bgardon@...gle.com>,
Jonathan Nieder <jrn@...gle.com>,
Alexei Starovoitov <ast@...nel.org>
Subject: public gerrit instance for kernel
Hi,
We've setup a public Gerrit instance for use with Linux kernel development:
https://linux.googlesource.com/Documentation/#gerrit-code-reviews-for-the-linux-kernel
After one-time setup changes can be pushed with a single command:
$ git push gerrit-net HEAD:refs/for/master
Gerrit has several (subjective) benefits over email-based reviews:
- full context (you can expand more context as necessary)
- diffs between version, e.g. full change is +547 lines:
https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2265/2
but diff between v1 and v2 is just 2 empty lines:
https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2265/1..2
(no need to write that up, trust subjective write ups)
- colored side-by-side diffs, e.g. here you can easily see that even
that line has changed it's only slash at the end that's added:
https://linux-review.googlesource.com/c/linux/kernel/git/torvalds/linux/+/2103/1/kunit/Makefile#2
- marking files as "reviewed", always correct base tree/revision, etc
But note there is no "official" story for gerrit in the linux process.
You may use it as you find fit. Some uses that we found useful so far:
- upload to do self-pre-review
- review within a team of people who agree to use gerrit
- include a link to gerrit into the upstream patch email as FYI
(after “---” line)
- upload somebody else patch just to review with side-by-side diffs
and full context
The branches are mirrored automatically from kernel.org; you can
upload changes for review against those branches, but submission has
to be routed through the traditional process.
If you are brave enough, you may use a gerrit-managed tree as well,
then with ability to merge/edit change on the web, non-losing comment
threads attached to lines of code, change status tracking, etc. But
that will need to be setup separately.
There are some improvements planned like not requiring Change-ID and
proxying comments to/from kernel mailing lists. But that's only in
plans now.
Thanks
Powered by blists - more mailing lists