On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <email@example.com> wrote:
> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <firstname.lastname@example.org> wrote:
>> However, then the "committer" of the contributed commits before the merge is
>> then the user, I guess?
>> (The rule meaning as suggested by Robin
>>> - if you include a commit from a user:
>>> author := non-@gentoo
>>> committer := @gentoo
>>> signer := $committer
> I guess, I'm not sure how the committer thing works in git.
Well, only Robin can explain exactly what he meant, but it sounds like
we don't want the committer field to ever have a non-gentoo email in
it, and signatures should be gentoo as well. So, if a dev just
applies a patch to their tree/etc then there is no issue (just set
author). If a dev wants to actually pull in a commit they'd need to
edit the fields accordingly and re-sign it. Not sure offhand how to
best do that (I assume it is possible - probably with some variation
on rebase or something rebase calls).
I don't think the intent is to snub non-devs. The issue is what is
the purpose of the signatures and committers field in the first place.
The signature verifies that the commit is intact, and you can only do
that if you have a key to check it with, and you can trust that key.
If the signer is a dev then we already have policy that the keys need
to be published, and we have a list of key IDs on our website. I'm
sure that could be improved on. If we stick non-dev signatures in the
tree then that becomes more of a problem (though it clearly is
possible - maybe something to think about). I assume the committer
denotes a layer of accountability, and having a dev in that spot makes
sense (devs who are proxies are accountable for oversight at some
level - though I'd personally give them the benefit of the doubt since
we want to encourage the proxy role).
I think the key with git is to not let the perfect be the enemy of the
good. We don't have an unbroken signature chain on our current
portage tree, so I don't think we need one to move to git. As long as
git is at least as good as what we have now, then we should accept it.
We should of course strive to improve, but let's not keep the almost
completely unsigned cvs around for another 10 years while we argue