On 06/04/2012 07:34 AM, Rich Freeman wrote:
> On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <djc@g.o> wrote:
>> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <dilfridge@g.o> 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)