On Tue, Oct 25, 2016 at 9:39 PM, Kent Fredric <ken...@gentoo.org> wrote: > > 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.
That actually isn't true. Read the DCO. Clauses b/c are designed specifically for cases where the committer isn't the author. It is apparently good enough for the Linux Foundation. They don't require any direct interaction with the author of code to accept it into the kernel. They merely require that whoever submits the code makes the certification that they've done their due diligence. > > And Pram should stop adding it everywhere post-haste, because its > inferring things that aren't true. > I did suggest that we probably should ban this header until we actually have a DCO because it blurs the lines. However, it isn't really inferring something that isn't true right now because we don't assign any legal meaning to the header right now. The bigger concern is that it blurs the lines after we have a DCO because people can argue the use of the header was accidental or meant something else. Whether or not we proactively ban the header, it would probably make sense that if we do institute a new copyright policy including a DCO that we ask all devs to explicitly ack the policy and the meaning of the signed-off-by header somehow (maybe issue a gpg signed statement from a template). It could also be made a part of the ebuild quiz or such so that all new devs ack it. I don't think we need to go nuts with it. Simply getting everybody to ack the policy makes it unambiguous that people understand what the header means. But, new policy or not the DCO really represents a practice that we should all be doing already. Nobody should be sticking code in a Gentoo repository without ensuring the licenses are compatible and so on. The DCO just represents a best practice that didn't exist when Gentoo started and which most projects now embrace in some form. It isn't that we didn't care about copyright in the past, we just care enough to be a little more formal about it in the future. > But this doesn't change the fact there is a desire to communicate other > properties of commits, like the audit trail for QA purposes. Sure. The repository should always make it clear who made each commit, when, and why (with appropriate bug x-refs and so on). Ideally it should somehow capture both who authored the code and who put it into the repository. I think for the most part we're already doing all of this, but I'm sure there is room for improvement (having a bug header in the default repoman commit template probably wouldn't hurt - then they all look the same and you can always delete it or leave it blank if it doesn't apply). -- Rich
