On Tue, Feb 21, 2006, Edgar Toernig wrote: > Johannes Stezenbach wrote: > > > > The meaning of the "Developer's Certificate of Origin" is > > clearly spelled out in Documentation/SubmittingPatches. > > If *the original patch author* (or copyright holder) refuses > > to give the Signed-off-by, the patch cannot be applied, > > for *legal* reasons. > > We must have different kernel trees. My SubmittingPatches says: ... > | The sign-off is a simple line at the end of the explanation for the > | patch, which certifies that you wrote it or otherwise have the right to > | pass it on as a open-source patch. ... > The only mentioned reason is history tracking. And nothing there forbids > a maintainer to be the first to sign off. Basically, if you don't sign-off your work, a maintainer _must_ assume that you either didn't write it yourself, or otherwise didn't have the right to pass it on as an open-source patch. Yeah, you need to know the background and read a bit between the lines. "history tracking" is a legal requirement, i.e. the necessary measures were taken to ensure that every patch was sent with the permission from the copyright holder. > > And actually you are also blocking others from fixing the > > problems, because they cannot copy your code and thus > > would have to come up with a different way of fixing it. > > Heh? It's GPLed code - it's meant to be copied/modified. It's code with unconfirmed copyright status. It is untouchable for Linux kernel purposes. If you ask why Linux needs this and other GPL projects not: I am not sure, however Linux is threatened by the SCO lawsuit, and other projects are not. I simply think that if you want to participate in Linux development, you need to respect Linus' way of dealing with this problem. What if someone independently writes the same fix? You could come and claim they ripped off your code. (Unless it's a really obvious one-liner, which IIRC isn't copyrightable, but IANAL.) > > > I don't care a bit whether the gatekeepers (for dvb-bt8xx there's no > > > one I would call a 'maintainer') > > > > Sounds somewhat arrogant, don't you think so? > > Wasn't meant to be. Note that I explicitly mentioned the dvb-bt8xx > driver - not the whole dvb subsystem. > > I got the impression there there's no one who really cares about the > dvb-bt8xx driver - like some unwanted stepchild. There are known > problems with the driver, fixes are available, but weeks later the > driver is still broken. Would _you_ call this a maintained driver? I hope by now you understand the reasons why your patches were not included. > In my opinion there's more to a driver maintainer than just feeding > contributed patches into cvs/mercurial or rejecting them. A driver > maintainer knows the hardware and the code and cares about his driver. > He takes patches/patchlets from random hackers, selects the proper parts > he's going to apply, reworks them so they match his quality standards > and his current working tree, fixes possible bugs, adds missing code, > sometimes even completely rewrites the stuff. Yeah, that would be nice. However, in the real world the maintainer has only very limited hardware resources, does it as a hobby in the evenings or weekends and not full time, doesn't have all the data sheets, doesn't have complete knowledge all of Linux, etc. IMHO a maintainer's main responsibility is to share his knowledge and experiences so _others_ can write better patches ;-) > What I found were just some gatekeepers with little to no knowledge > about the driver itself who act like subsystem maintainers demanding > perfect patches. "gatekeeper" is an offense which totally misses the point. Of course a maintainer has to reject patches when he thinks they are wrong. But to err is human, if you think the maintainer is wrong you need to convince him. Be patient, write up the facts, find others to back up your posistion etc. "little to no knowledge" is another offense. No one knows everything. "demanding perfect patches" isn't strictly true, but it's usual in Linux development that the patch author is responsible for conforming to Documentation/CodingStyle, Documentation/SubmittingPatches etc., and of course addressing stylistic or architectural concerns by the maintainer. Otherwise every other changeset in the kernel would be "cleanup the mess created by the previous patch", since the origin tracking requirement prevents combining patches from different authors (except for very simple things like whitespace cleanup). Patches get also posted to lkml when they are forwarded to Linus, and sometimes the friendly hackers hanging out there take the time to look over them, and report coding style issues. So it's in our interest to follow them right from the start. > But I won't complain. That may be the way how the dvb subsystem is > managed. I'm just some random hacker who fixed problems he had with > the drivers for his hardware and who made the fixes public. Whether > they make it into the kernel or not is not very important for me - I > got my hardware working. It may help other people though. > > I think I answered every question regarding the patch to help main- > tainers decide what to do - the rest is up to them. > > Just do whatever you want with the patches. Please resend them with your Signed-off-by:. Otherwise we can't touch them. Take it from me, DVB doesn't want to be special, we just try to follow the rules set by Linus (because of legal requirements, not because he thinks it's fun) in the same way as other subsystems do it. Thanks, Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
