On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <[email protected]> wrote: > On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <[email protected]> > 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 about signatures. Rich
