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-l...@collabora.com> writes: >> >>> On Wed, 2018-11-28 at 13:43 -0800, Eric Anholt wrote: >>>> Jordan Justen <jordan.l.jus...@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.jus...@intel.com> >>>>> Cc: Matt Turner <matts...@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
pEpkey.asc
Description: application/pgp-keys
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
