[linux-dvb] Patch collection for bt8xx cards

Edgar Toernig froese at gmx.de
Tue Feb 21 05:57:49 CET 2006


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 at developer.example.org>
|
| 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.



More information about the linux-dvb mailing list