On 2018-11-29 15:53:09, 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."
Yeah, I can see how that can happen in some cases. Hopefully the feedback to the contributor would be, go read about patch signing in docs/submittingpatches.html rather than just "add Signed-off-by". It sounds like the biggest drawback is that some casual contributors might be turned off from making the contribution because they need to read the DCO and revise their patch. Could it be argued that such contributions are not neccessarily worth the time then? If they treat a code contribution this cavalierly, then maybe a bug report would be more their speed? > We've already got 1-2 people to contact if there's a question about > authorship, from the committer and author fields. There's also the missed opportunity for them to think about the license issue. (Maybe not 100% will seriously think about it, but will it be 0%?) Sometimes I'm shocked about how many projects I find on github with absolutely no license in sight. It's like, oh that's cool, but I guess it's not usable by anyone for anything. :\ So, maybe it's not so bad to add this if we might also be inviting in the pull/merge request crowd? :) It seems like you are annoyed, or at least skeptical about this. Is that a "NAK", or "why?", or "alright, but it's a waste of time"? -Jordan _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
