[Mesa-dev] [PATCH] docs: Document and *require* usage of Signed-off-by

[apinheiro]

On 30/11/18 17:32, Ian Romanick wrote:
> On 11/29/2018 03:53 PM, Eric Anholt wrote:
>> e<#secure method=pgpmime mode=sign>
>> Erik Faye-Lund <erik.faye-lund at collabora.com> writes:
>>
>>> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote:
>>>> Jordan Justen <jordan.l.justen at intel.com> writes:
>>>>
>>>>> This adds the "Developer's Certificate of Origin 1.1" from the
>>>>> Linux
>>>>> kernel. It indicates that by using Signed-off-by you are certifying
>>>>> that your patch meets the DCO 1.1 guidelines.
>>>>>
>>>>> It also changes Signed-off-by from being optional to being
>>>>> required.
>>>>>
>>>>> Signed-off-by: Jordan Justen <jordan.l.justen at intel.com>
>>>>> Cc: Matt Turner <mattst88 at gmail.com>
>>>> What problem for our project is solved by signed-off-by?  Do you
>>>> think
>>>> that it has actually reduced the incidence of people submitting code
>>>> they don't have permission to submit in the projects where it's been
>>>> used?  I know the behavior in the kernel is that people submit a
>>>> patch,
>>>> it's missing s-o-b, so it gets bounced, then they maybe add s-o-b or
>>>> just give up.  I don't think anyone stops and says "Wow, that's a
>>>> good
>>>> question.  Maybe I don't have permission to distribute this after
>>>> all?"
>>>>
>>>> /me sees s-o-b as basically just a linux kernel hazing ritual
>>> I don't think that's the purpose of s-o-b in the Kernel. AFAIK, the
>>> reason for the s-o-b is to have a paper-trail for how a patch landed in
>>> the kernel; who it went through etc.
>> I get the *idea*, I just believe the idea fails in practice.  The S-O-B
>> idea came from "wouldn't it be nice if we could make everyone think
>> about this issue that is important to us" but what we actually got
>> instead is "your patch gets bounced if you don't have a s-o-b on until
>> you slap one on and resend."
> You're thinking like an engineer, but the s-o-b is the spawn of lawyers.
>  Supposedly, having someone say "I had the rights to contribute this
> code," even if they didn't think about what that meant, enables you to
> pass that blame along because that person showed intent.  You may not
> have read and thought about every page of your mortgage, but you can
> still be held accountable for every word.  Having an author tag or a
> committer tag does not show that same intent.  In a legal context, the
> s-o-b shifts the onus of auditing code ownership from the distributor to
> the submitter.  When a distributor, like IBM in the SCO case, get sued,
> they can plausibly claim that all of the code they distributed was
> vouched for.  If someone submits code that they do not have the right to
> submit and provides false testimony, then that's on the submitter.
>
> S-o-b for that purpose always seemed pretty lame to me (from any
> perspective) because patches aren't digitally signed.  Anyone can add
> any s-o-b to any patch, spoof the sending address, etc.
>
> The s-o-b is also mostly an anachronism of taking patches via mailing
> list.  Projects that exclusively use GitHub or similar have everyone
> sign an SLA, and every patch that comes in through the submission
> mechanism, guarded by a login, is implicitly signed.
>
>> We've already got 1-2 people to contact if there's a question about
>> authorship, from the committer and author fields.
> That's one thing that annoys me from time to time about git.  Five
> people may have worked on a patch, but it only shows one author.


FWIW, although I usually don't use the s-o-b, I tend to use it when more
than one person works on a patch. So for some of our work, we keep the
author as the one that initially created the patch, and if we have
several people touching it, we add several s-o-b on the patch. Now
reading the thread, perhaps that was somewhat silly, but looked like the
best/easier solution to give some authorship to everyone.


BR



-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1546 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181219/00867041/attachment.key>