Gentoo Archives: gentoo-dev

From: Mike Gilbert <floppym@g.o>
To: Gentoo Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
Date: Thu, 12 Jul 2018 04:35:57
Message-Id: CAJ0EP41zPzuyHyb_uukq0fpw+yaOQOsR3R2yMcK6G_dRuncw9A@mail.gmail.com
In Reply to: Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address by Kent Fredric
1 On Wed, Jul 11, 2018 at 11:52 PM, Kent Fredric <kentnl@g.o> wrote:
2 > On Mon, 09 Jul 2018 10:40:22 +0200
3 > Michał Górny <mgorny@g.o> wrote:
4 >
5 >> Hi,
6 >>
7 >> We currently don't enforce any particular standard for e-mail addresses
8 >> for developers committing to gentoo.git. FWICS, the majority of
9 >> developers is using their @gentoo.org e-mail addresses. However, a few
10 >> developers are using some other addresses.
11 >>
12 >> Using non-@g.o e-mail addresses generally causes problems
13 >> in accounting for commits. For example, our retirement scripts can't
14 >> detect commits made using non-Gentoo e-mail address. My dev-timeline
15 >> scripts [1] account for all emails in LDAP (which doesn't cover all
16 >> addresses developers use). FWIK gkeys accounts for all addresses
17 >> in the OpenPGP key UIDs. In my opinion, that's a lot of hoops to jump
18 >> through to workaround bad practice.
19 >>
20 >> Therefore, I'd like to start enforcing (at the level of the hook
21 >> verifying signatures) that all commits made to gentoo.git (and other
22 >> repositories requiring dev signatures) are made using @gentoo.org e-mail
23 >> address (for committer field).
24 >>
25 >> Is anyone opposed to that? Does anyone know of a valid reason to use
26 >> non-@g.o address when committing?
27 >>
28 >> [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html
29 >>
30 >
31 > There's one fun problem here technologically for proxy-maint, but
32 > getting the conditions right for it to occur happen very rarely.
33 >
34 > 1. Assume the proxied maintainer has a git repo, where they commit
35 > themselves.
36 >
37 > 2. Assume their proxy has said git repo as an alternative remote, for
38 > which they relay work. ( That is, they work closely together directly
39 > instead of via github pull requests and textual patches )
40 >
41 > 3. ::gentoo is quiet, and the proxied maintainer has rebased their own
42 > work on top of ::gentoo, setting Committer: metadata and signing
43 > commits.
44 >
45 > Then, in that situation, it is trivial for the proxy to relay those
46 > commits verbatim to ::gentoo, without changing either Committer: or
47 > signature data.
48 >
49 > Standard git tools will not attempt to even *change* these commits even
50 > with an explicit rebase, because Git will detect that nothing needs to
51 > change, and will no-op the rebase, leaving Committer and Signatures
52 > intact, degrading to a fast-forward merge.
53 >
54 > It seems like it would happen not-very-often, but ...
55 >
56 > git log --show-signature --format=fuller --committer=".*@\([^g]\|g[^e]\)"
57 >
58 > Well, the last example happened in 2017, so maybe something happened
59 > *since* then that prevented this situation occurring via other means?
60 > *shrug*
61 >
62 >
63 > commit 76eb43412b532a045d92d524dfa5ed1b1bcca671
64 > Author: Michael Mair-Keimberger <m.mairkeimberger@×××××.com>
65 > AuthorDate: 2017-10-02 02:47:28 +1300
66 > Commit: Michael Mair-Keimberger <m.mairkeimberger@×××××.com>
67 > CommitDate: 2017-10-10 07:45:09 +1300
68 >
69 > To the best of my knowledge, Michael isn't a Gentoo Dev.
70
71 This was incorporated into the master branch via a merge commit, not a
72 fast-forward or a rebase. See
73 6711d4f96985b0797c1803cd6f05e5a1410c1018.
74
75 We have generally discouraged merge commits, but they do occasionally happen.