Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Rich Freeman <rich0@g.o>
Subject: Re: Git braindump: 1 of N: merging & git signing
Date: Mon, 4 Jun 2012 08:34:30 -0400
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


Replies:
Re: Git braindump: 1 of N: merging & git signing
-- Matthew Thode
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
References:
Git braindump: 1 of N: merging & git signing
-- Robin H. Johnson
Re: Git braindump: 1 of N: merging & git signing
-- Andreas K. Huettel
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Re: Git braindump: 1 of N: merging & git signing
-- Andreas K. Huettel
Re: Git braindump: 1 of N: merging & git signing
-- Dirkjan Ochtman
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Git braindump: 1 of N: merging & git signing
Next by thread:
Re: Git braindump: 1 of N: merging & git signing
Previous by date:
[java-utils-2.eclass] - removal of java-pkg_ensure-test and java-pkg_ensure-gcj
Next by date:
Re: Git braindump: 2 of N: developer interaction (merge co-ordinators)


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.