[linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)

Johannes Stezenbach js at linuxtv.org
Thu Jul 12 00:37:44 CEST 2007

On Thu, Jul 12, 2007 at 03:49:30AM +1000, Julian wrote:
> Since this disscussion is public...
> I'm going to put in my 2 cents.
> If you actually read his posts - Like alot of end users are. Its the flames 
> and personal attacks that are coming from the group mentality here (im sure 
> theres a wiki that can explain that too)

Hm, Markus complains that the community doesn't work, and you're
complaining that it _does_ work -- or what do you mean by
"group mentality"?

> So if we are talking about changes to the core and how v4l and dvb devices 
> will work under linux in the future. He/they with the best solution will win 
> via non-bias peer review and hopefully *beyond* the linuxtv project. So if 
> Markus persists enough (he seems the only one consistently reworking what he 
> has already done - but everyone seems to skim past that in his posts...) he 
> will succeed.
> I admire anyone that makes an effort against the status quo that fails to move 
> anywhere really, and spends more effect resisting any kind of change than 
> actually doing anything or offering an alternative.
> Just because he is outnumbered with support here means absolutely nothing.
> May the best code win.

Markus always portrays it that way, that there is a group of evil
guys who block his code, who mislead him, who want to retain the
status quo etc. pp.  And now he is the lonely hero who stands up
against the establishment...

IMHO that is complete rubbish. There isn't even a formal group
of "linuxtv core developers". I'm glad that Mauro agreed to
merge the DVB and V4L trees into one, and to do the patch handling
for the combined tree. And I'm glad Mike and Trent do a lot of
patch review and bugfixing work, unseen and unrewarded
my most people. Does that give them any authority to ACK and NACK
patches as they see fit? Hell, no! But the community process works
that way that if someone reviews a patch and has objections, then
these objections must either be addressed or shown to be wrong.
(Read Documentation/ManagementStyle in the kernel to see how it works ;-)

In Markus case, serveral people who looked at his patches had
objections, but he refused to address them, but was unable to
either show the objections as being wrong, or get a _single_ other
developer to back up his position. Instead there were threats
to "fork the linuxtv project" if his code wouldn't get merged...

The sad thing is that only a relatively small part of Markus'
code has problems, and the bulk of it could have been merged
without it, leaving out the xc3028 v4l/dvb arbitration functionality.
But Markus didn't want this.

Anyway, there are many patches which are rejected from the
Linux kernel or have to go through significant transformations
before they are allowed into the kernel. You should read the
linux kernel mailing list for a while, maybe you'd then see
that the entry level for patches into v4l/dvb is fairly low
compared to the high standards required for core kernel code
like scheduler, timekeeping, networking, VM, block IO layer etc.

> >Your attempts to force the merge with flames and ultimatums
> >(yes, plural) failed. Surprise, surprise...
> how soft do people get with their drivers that they see a patch submission - 
> as a flame?

That's not what I said, I can tell a patch submission from a flame
quite well, thanks.


More information about the linux-dvb mailing list