On Wed, Jul 11, 2018 at 11:52 PM, Kent Fredric <ken...@gentoo.org> wrote:
> On Mon, 09 Jul 2018 10:40:22 +0200
> Michał Górny <mgo...@gentoo.org> wrote:
>> Hi,
>> We currently don't enforce any particular standard for e-mail addresses
>> for developers committing to gentoo.git.  FWICS, the majority of
>> developers is using their @gentoo.org e-mail addresses.  However, a few
>> developers are using some other addresses.
>> Using n...@gentoo.org e-mail addresses generally causes problems
>> in accounting for commits.  For example, our retirement scripts can't
>> detect commits made using non-Gentoo e-mail address.  My dev-timeline
>> scripts [1] account for all emails in LDAP (which doesn't cover all
>> addresses developers use).  FWIK gkeys accounts for all addresses
>> in the OpenPGP key UIDs.  In my opinion, that's a lot of hoops to jump
>> through to workaround bad practice.
>> Therefore, I'd like to start enforcing (at the level of the hook
>> verifying signatures) that all commits made to gentoo.git (and other
>> repositories requiring dev signatures) are made using @gentoo.org e-mail
>> address (for committer field).
>> Is anyone opposed to that?  Does anyone know of a valid reason to use
>> n...@gentoo.org address when committing?
>> [1]:https://dev.gentoo.org/~mgorny/dev-timeline.html
> There's one fun problem here technologically for proxy-maint, but
> getting the conditions right for it to occur happen very rarely.
> 1. Assume the proxied maintainer has a git repo, where they commit
> themselves.
> 2. Assume their proxy has said git repo as an alternative remote, for
> which they relay work. ( That is, they work closely together directly
> instead of via github pull requests and textual patches )
> 3. ::gentoo is quiet, and the proxied maintainer has rebased their own
> work on top of ::gentoo, setting Committer: metadata and signing
> commits.
> Then, in that situation, it is trivial for the proxy to relay those
> commits verbatim to ::gentoo, without changing either Committer: or
> signature data.
> Standard git tools will not attempt to even *change* these commits even
> with an explicit rebase, because Git will detect that nothing needs to
> change, and will no-op the rebase, leaving Committer and Signatures
> intact, degrading to a fast-forward merge.
> It seems like it would happen not-very-often, but ...
> git log --show-signature --format=fuller --committer=".*@\([^g]\|g[^e]\)"
> Well, the last example happened in 2017, so maybe something happened
> *since* then that prevented this situation occurring via other means?
> *shrug*
> commit 76eb43412b532a045d92d524dfa5ed1b1bcca671
> Author:     Michael Mair-Keimberger <m.mairkeimber...@gmail.com>
> AuthorDate: 2017-10-02 02:47:28 +1300
> Commit:     Michael Mair-Keimberger <m.mairkeimber...@gmail.com>
> CommitDate: 2017-10-10 07:45:09 +1300
> To the best of my knowledge, Michael isn't a Gentoo Dev.

This was incorporated into the master branch via a merge commit, not a
fast-forward or a rebase. See

We have generally discouraged merge commits, but they do occasionally happen.

Reply via email to