[linux-dvb] Patch collection for bt8xx cards

Johannes Stezenbach js at linuxtv.org
Tue Feb 21 12:45:41 CET 2006

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.


More information about the linux-dvb mailing list