On Mon, 24 Oct 2016 07:45:56 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> I don't think we need a git header for the purpose of saying that > something looks good to somebody else. If you commit something and it > doesn't work, we'll ask you to stop doing it. If you keep doing it > we'll take away your commit access. This is purely an internal > problem. The problem is that the COMMITTER and AUTHOR headers don't actually reflect the "I tested it and made sure its OK" metadata. If for example, a commit made to Gentoo was replicated to another repository by cherry-pick, the default mechanic would result in COMMITTER changing to the person who performed the cherry-pick. Thus, it makes the assumption that everyone who performed a COMMIT action or an AUTHOR action verified the nature of the commit in some manner. However, the AUTHOR is the least qualified to verify the commit as "Good". and the COMMITTER value changes arbitrarily if you try to cherry-pick or rebase the commit sequence. And people who rebase commit sequences are typically not firing up review engines for every commit they rebased. Granted, this is not a very common problem in Gentoo. But IME, this is the sort of use-case that the header is useful for. If we deem this header useless, then we should probably consider dropping the Portage Version and Repoman Flags headers that repoman adds. Because they're also made entirely irrelevant in very short times, because it only indicates "Authored with", it doesn't indicate anything that happened since then. > The purpose of a DCO is to withstand external scrutiny. It helps > protect Gentoo in the event that somebody else's copyrighted code > makes it into the distro. The audience for a signed-off-by header > isn't Comrel or QA, but rather a court of law. It makes it harder to > contribute something to Gentoo and then argue that you didn't intend > for Gentoo to redistribute it under the GPL, or that now that you've > had a falling out you'd prefer that Gentoo remove all your past > contributions. > > However, it has absolutely no meaning at all if it isn't 100% clear > what is being signed. And if we have a long history of people adding > the header when it doesn't mean anything legally then it will probably > make it harder to argue that it suddenly means something when the > policy changes. > > For example, suppose we institute a DCO tomorrow. Then zlg ragequits > in 2 years and claims he never gave us permission to redistribute his > code under the GPL. We point to his signed-off-by headers but he says > he never heard of the DCO policy and that it was just some default > setting in his config, and that he was adding the headers long before > the policy went into effect. I don't think it would stick but it > really isn't an out we want to give people. IMO infra should reject > commits with this header until we have a DCO, and then it should > reject commits without this header. Alternatively, we could skip the > first part but require all existing devs to ack the new copyright > policy whenever it happens. Under this interpretation, developers using this header to add other peoples work to tree is making our use of DCO pointless. Because DCO has to be the person who *authored* the commit, not the person who merely added it to tree. And Pram should stop adding it everywhere post-haste, because its inferring things that aren't true. But this doesn't change the fact there is a desire to communicate other properties of commits, like the audit trail for QA purposes. It just means we have to find some other way of doing this which is standard, but the stock git commands lack any such mechanism.
pgpocxPgRq2WX.pgp
Description: OpenPGP digital signature
