Gentoo Archives: gentoo-dev

From: Kent Fredric <kentnl@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way
Date: Wed, 26 Oct 2016 01:39:48
Message-Id: 20161026143914.3c799c9a@katipo2.lan
In Reply to: Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way by Rich Freeman
1 On Mon, 24 Oct 2016 07:45:56 -0400
2 Rich Freeman <rich0@g.o> wrote:
3
4 > I don't think we need a git header for the purpose of saying that
5 > something looks good to somebody else. If you commit something and it
6 > doesn't work, we'll ask you to stop doing it. If you keep doing it
7 > we'll take away your commit access. This is purely an internal
8 > problem.
9
10 The problem is that the COMMITTER and AUTHOR headers don't actually
11 reflect the "I tested it and made sure its OK" metadata.
12
13 If for example, a commit made to Gentoo was replicated to another
14 repository by cherry-pick, the default mechanic would result in
15 COMMITTER changing to the person who performed the cherry-pick.
16
17 Thus, it makes the assumption that everyone who performed a COMMIT
18 action or an AUTHOR action verified the nature of the commit in some
19 manner.
20
21 However, the AUTHOR is the least qualified to verify the commit as
22 "Good".
23
24 and the COMMITTER value changes arbitrarily if you try to cherry-pick or
25 rebase the commit sequence.
26
27 And people who rebase commit sequences are typically not firing up
28 review engines for every commit they rebased.
29
30 Granted, this is not a very common problem in Gentoo.
31
32 But IME, this is the sort of use-case that the header is useful for.
33
34 If we deem this header useless, then we should probably consider
35 dropping the Portage Version and Repoman Flags headers that repoman
36 adds.
37
38 Because they're also made entirely irrelevant in very short times,
39 because it only indicates "Authored with", it doesn't indicate anything
40 that happened since then.
41
42 > The purpose of a DCO is to withstand external scrutiny. It helps
43 > protect Gentoo in the event that somebody else's copyrighted code
44 > makes it into the distro. The audience for a signed-off-by header
45 > isn't Comrel or QA, but rather a court of law. It makes it harder to
46 > contribute something to Gentoo and then argue that you didn't intend
47 > for Gentoo to redistribute it under the GPL, or that now that you've
48 > had a falling out you'd prefer that Gentoo remove all your past
49 > contributions.
50 >
51 > However, it has absolutely no meaning at all if it isn't 100% clear
52 > what is being signed. And if we have a long history of people adding
53 > the header when it doesn't mean anything legally then it will probably
54 > make it harder to argue that it suddenly means something when the
55 > policy changes.
56 >
57 > For example, suppose we institute a DCO tomorrow. Then zlg ragequits
58 > in 2 years and claims he never gave us permission to redistribute his
59 > code under the GPL. We point to his signed-off-by headers but he says
60 > he never heard of the DCO policy and that it was just some default
61 > setting in his config, and that he was adding the headers long before
62 > the policy went into effect. I don't think it would stick but it
63 > really isn't an out we want to give people. IMO infra should reject
64 > commits with this header until we have a DCO, and then it should
65 > reject commits without this header. Alternatively, we could skip the
66 > first part but require all existing devs to ack the new copyright
67 > policy whenever it happens.
68
69 Under this interpretation, developers using this header to add other
70 peoples work to tree is making our use of DCO pointless.
71
72 Because DCO has to be the person who *authored* the commit, not the
73 person who merely added it to tree.
74
75 And Pram should stop adding it everywhere post-haste, because its
76 inferring things that aren't true.
77
78 But this doesn't change the fact there is a desire to communicate other
79 properties of commits, like the audit trail for QA purposes.
80
81 It just means we have to find some other way of doing this which is
82 standard, but the stock git commands lack any such mechanism.

Replies

Subject Author
Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way Rich Freeman <rich0@g.o>