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