Gentoo Archives: gentoo-dev

From: Matthew Thode <prometheanfire@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing
Date: Mon, 04 Jun 2012 14:04:59
Message-Id: 4FCCC016.5090306@gentoo.org
In Reply to: Re: [gentoo-dev] Git braindump: 1 of N: merging & git signing by Rich Freeman
1 On 06/04/2012 07:34 AM, Rich Freeman wrote:
2 > On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman <djc@g.o> wrote:
3 >> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel <dilfridge@g.o> wrote:
4 >>> However, then the "committer" of the contributed commits before the merge is
5 >>> then the user, I guess?
6 >>>
7 >>> (The rule meaning as suggested by Robin
8 >>>> - if you include a commit from a user:
9 >>>> author := non-@gentoo
10 >>>> committer := @gentoo
11 >>>> signer := $committer
12 >>
13 >> I guess, I'm not sure how the committer thing works in git.
14 >>
15 >
16 > Well, only Robin can explain exactly what he meant, but it sounds like
17 > we don't want the committer field to ever have a non-gentoo email in
18 > it, and signatures should be gentoo as well. So, if a dev just
19 > applies a patch to their tree/etc then there is no issue (just set
20 > author). If a dev wants to actually pull in a commit they'd need to
21 > edit the fields accordingly and re-sign it. Not sure offhand how to
22 > best do that (I assume it is possible - probably with some variation
23 > on rebase or something rebase calls).
24 >
25 > I don't think the intent is to snub non-devs. The issue is what is
26 > the purpose of the signatures and committers field in the first place.
27 > The signature verifies that the commit is intact, and you can only do
28 > that if you have a key to check it with, and you can trust that key.
29 > If the signer is a dev then we already have policy that the keys need
30 > to be published, and we have a list of key IDs on our website. I'm
31 > sure that could be improved on. If we stick non-dev signatures in the
32 > tree then that becomes more of a problem (though it clearly is
33 > possible - maybe something to think about). I assume the committer
34 > denotes a layer of accountability, and having a dev in that spot makes
35 > sense (devs who are proxies are accountable for oversight at some
36 > level - though I'd personally give them the benefit of the doubt since
37 > we want to encourage the proxy role).
38 >
39 > I think the key with git is to not let the perfect be the enemy of the
40 > good. We don't have an unbroken signature chain on our current
41 > portage tree, so I don't think we need one to move to git. As long as
42 > git is at least as good as what we have now, then we should accept it.
43 > We should of course strive to improve, but let's not keep the almost
44 > completely unsigned cvs around for another 10 years while we argue
45 > about signatures.
46 >
47 > Rich
48 >
49 I think the intent is to only have commits and signoffs come from
50 @gentoo, but we need a way to give attribution to users who send stuff
51 in that gets committed.
52
53 --
54 -- Matthew Thode (prometheanfire)

Attachments

File name MIME type
signature.asc application/pgp-signature