On 06/04/2012 07:34 AM, Rich Freeman wrote: > 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 > I think the intent is to only have commits and signoffs come from @gentoo, but we need a way to give attribution to users who send stuff in that gets committed.
-- -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital signature
