Johannes Stezenbach wrote: > > On Mon, Feb 20, 2006, Edgar Toernig wrote: > > > > If the committer wants to track patch history he can put me in > > as the author or add a 'Submitted-by'. If he thinks he cannot > > sign off himself without someone else signing first I can only > > say "Welcome to the Club". > > Unfortunately this doesn't work. The Signed-off-by thing was > Linus' answer to the SCO lawsuit and related legal issues. > 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: | 11) Sign your work | | To improve tracking of who did what, especially with patches that can | percolate to their final resting place in the kernel through several | layers of maintainers, we've introduced a "sign-off" procedure on | patches that are being emailed around. | | 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 rules are pretty simple: if you | can certify the below: | | Developer's Certificate of Origin 1.1 | [...] | | then you just add a line saying | | Signed-off-by: Random J Developer <random@xxxxxxxxxxxxxxxxxxxxx> | | Some people also put extra tags at the end. They'll just be ignored for | now, but you can do this to mark internal company procedures or just | point out some special detail about the sign-off. The only mentioned reason is history tracking. And nothing there forbids a maintainer to be the first to sign off. > Well, I can't keep you from sending it, but without Signed-off-by > it can't be applied. :-( But other people may find it and get their card working. > 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. > > 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? 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. What I found were just some gatekeepers with little to no knowledge about the driver itself who act like subsystem maintainers demanding perfect patches. 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. Ciao, ET. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
