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) |