Re: thoughts on a Merge Request based development workflow

[Han-Wen Nienhuys <hanwen@google.com>]

On Tue, Oct 15, 2019 at 8:37 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Mon, Oct 14, 2019 at 09:08:17PM +0200, Han-Wen Nienhuys wrote:
>
> >To 2) : Google needs special magic sauce, because we service hundreds
> >of teams that work on thousands of repositories. However, here we're
> >talking about just the kernel itself; that is just a single
> >repository, and not an especially large one.  Chromium is our largest
> >repo, and it is about 10x larger than the linux kernel.
>
> Kernel isn't a single repository -- most maintainers have their own fork
> or multiple. Git.kernel.org is now over a thousand repositories (mostly
> forks of the kernel).

I've heard this before, but it's not clear what problem you are
solving in this way. They're all based on the same commit graph, so it
could just be a single repo with 1000 branches.

> >Git is a tool built to exchange code and diffs. It seems natural to
> >build a review solution on top of Git too. Gerrit is also built on top
> >of git, and stores all metadata in Git too, ie. you can mirror review
> >data into other Gerrit instances losslessly.
>
> As I see it, there are the following things that would make Gerrit a
> difficult proposition:
>
> 1. A gerrit instance would introduce a single source of failure, which
>    is something many see as undesirable. If there's a DoS attack, Google
>    can restrict access to their Gerrit server to limit the requests to
>    only come from their corporate IP ranges, but kernel.org cannot do
>    the same, so anyone relying on gerrit.kernel.org cannot do any work
>    while it is unavailable.

I don't understand your scenario. Are you concerned that Google would
protect DoS attacks by limiting traffic to the corp network?

Or are you concerned that kernel.org has no DoS protection?

How does DoS protection for kernel.org work today? If someone DoSes
git.kernel.org with its 1000s of git trees, how do people get work
done?

> 2. There is limited support for attestation with Gerrit. A change
>    request can contain a digital signature, but any comments surrounding
>    it do not. It would be easy for the administrator of the gerrit
>    instance to forge a +1 or +2 on a CR making it look like it came from
>    the maintainer or the CI service (in other words, we are back to
>    explicitly trusting the infrastructure and IT admins).

Does anyone use attestation/PGP signing for their code reviews that
are conducted over Email? How many people use PGP signing on their
commits?

How does email figure into this story? Email has no authentication at
all, so if this is a requirement, you should probably stop using email
for reviews.

> 3. There is no email bridge, only notifications. Switching to gerrit
>    would require a flag-day when everyone must start using it (or stop
>    participating in kernel development).

Gerrit sends out email for comments. If you reply to that email,
Gerrit ingests the comment and puts it in the review.

> >By contrast, a centralized server can authenticate users reliably and
> >the server owner can define such rules.  There can still be multiple
> >gerrit servers, possibly sponsored by corporate entities (one from
> >RedHat, one from Google, etc.), and different servers can support
> >different authentication models (OpenID, OAuth, Google account, etc.)
>
> How would multiple Gerrit servers operate if they are backed by
> different authentication models? Something like a replication plugin
> would require that each of these instances are fully trusted sources of
> truth. I am not sure Red Hat would be happy to fully trust a replication
> stream coming from its direct market competitors, especially if they are
> in a position to forge identities.
>
> Or do you mean they are separate instances and a maintainer would pick
> where to host their subsystem? But then, if they pick Google's gerrit
> system, how would engineers from China be able to participate?

I mean the latter.

The question about China is a good one. If access from China (and
Iran, North Korea, etc.) is a requirement, that would be useful to
document.

> Generally, unless there is a way to run Gerrit without explicitly
> trusting the infrastructure and admins, I will be in strong opposition
> to choosing it as the solution.
>
> -K



-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado