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