On Thursday 28 June 2007 22:35, Sascha Sommer wrote:
> Hi,
>
> On Thursday 14 June 2007 23:05, Markus Rechberger wrote:
> > Hi,
> >
> > since I officially take care about the latest Empia em28xx code I
> > want to get that project removed from linuxtv.org.
> > Mauro already broke some parts in the incomplete inkernel linux
> > driver. Since the few developers here who cannot just shut their
> > mouth and accept others work I don't see another way out.
> > I will rebase the code a last time and add a binary module
> > interface to the em28xx driver to allow the usage of proprietary
> > dvb-t demod and tuner code from userspace. Mauro is probably aware
> > of wasting my time, and the 3-4 other people who are against 1 1/2
> > years of work which has been done are probably aware either of it.
> >
> > I will stop any further cooperation with that project since I
> > simply don't have the time for all these useless flamewars with
> > people who don't know it better.
> >
> > If opensource isn't entirely possible because of a flawed community
> > it's better to go binary.
>
> Can someone please summarize these flamewars and especially the
> remaining problems?
> Why can you people spend hours reverseegineering all kinds of
> obfuscated hardware while not being able to work out a plan to
> resolve this issue? This is really a shame.
> No, it wasn't very nice to see the em28xx driver (that is based on
> the Cinergy 200 USB driver that I started in 2004) in video4linux cvs
> without support for the cards that were originally supported by the
> Cinergy driver. However instead of whining I sent a patch to readd
> these devices.
> I don't see how a em28xx driver that is seperated from video4linux is
> an improvement in any way. It should have never gotten into this
> state. Markus, what will happen with your code? Do you intend to
> merge it into the kernel someday later? Won't there be more
> conflicts? Why do we suddenly need a binary module interface?
> Working 1 1/2 years on your own tree and then expecting everything to
> be merged in one big hunk is not fair. During this time I also sent
> you patches for the em2800 cards that were never added to the
> mainline kernel because you wanted to merge your changes first. What
> will happen with my patches? Can't we just get through your patchset
> and apply the codefixes and work out the tuner problems afterwards?
> Your code is not useless. During my tests your version of the em2800
> driver worked much better than the current kernel code. I want that
> the codebases get unified again and promise to help during my
> semester break in august. I'm afraid if this problem cannot get
> solved now, solving it in the future will not be possible either.
Hi Sascha,
I've been following this whole process for quite some time now and also
tried to help out. I've come to the conclusion that it is purely due to
bad chemistry between various personalities. Technically this stuff
should have been merged a year ago if not earlier. It is really sad,
but it happens sometimes. There also isn't one person to blame,
it's 'just' personality conflicts that caused this mess.
It's my conclusion that in the interest of the end-user Markus' approach
is probably the best. Not technically the best: that would be if
everybody got their act together and just worked towards merging it
into the kernel. I've looked at the code and I think with perhaps a few
evenings of work and everybody behaving reasonably it could be merged.
But the end-user couldn't care less about this situation and just wants
to have a working driver. Perhaps in the future when different people
step in this might be resolved better.
Regards,
Hans
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
