On 3/9/07, Steven Toth <stoth@xxxxxxxxxxxxx> wrote:
>> That someone fucks up and talks bullshit, that's >> to be expected from a human being. >> But that's something entirely different than malice. >> >> > > In January 2006 I got told that I should implement the xc3028 just as > all other external tuner modules are implemented without a tuner-core > dependency, it end up that the tuner-core would need modularization > since all external v4l tuners are compiled into the tuner-core. > Markus, I suspect the other person gave the best advice they could at the time. Maybe that advise is no longer true or valid. Either way, the person offered the best advise I suspect. Maybe in the future you should seek advise from multiple sources to validate any long term development approach.
everyone is welcome to reply, but usually not too many participate here.
For anyone to turn around and complain sounds petty and unprofessional. If you're really interested in moving the general Linux community forward
sorry that's not on me I already showed up quite alot interest by writing and discovering how many em28xx devices work even without having the proper specs for it. I'm also behind bugreports and normal user help I receive on a daily basis and there are already several thousand mails about it in my mailaccount. I just spent too much time on it for getting cut down by people who don't want to go forward. Also these 8000 lines of new code didn't write themself.
then you will stop henceforth blaming other people and aggressively push two or three alternative solutions. If you are passionate enough about your work then you need to promote your ideas enough that people either accept one of your suggestions, or recommend an alternative approach. Passion and perseverance is required, not moaning. Likewise, the other developers have an obligation to review your ideas and discuss/describe the areas of concern, offering constructive feedback. It's unacceptable to refuse a colleagues patch and not offer any advise. I know this has NOT happened. I know alternatives were given to you.
What alternatives do you mean? * writing several wrappers around a core driver? -- is this really acceptable, what are the pros/cons of that approach? * writing one wrapper for dvb? - same what are the pros/cons. * it also got stated out if there's any way to merge tuner core code with dvb-pll (in that case only dvb_tuner_ops) it would be welcome (got also only mentioned only by a few devs) I triggered 2 discussions about that already and the participation of other developers was quite low. - * looking at the saa7134-dvb hybrid driver, which I did and I took the v4l infrastructure for tuning to dvb channels since it was done that way too, of course some DVB guys didn't like that approach either when they saw it the first time...
I suggest you stop the bickering and begin working with your Linux peers again, help us to find the right solution.
sorry I'm getting pissed, for every approach I presented for now I had some code as well and it gets nacked without improvement suggestions. Also it has to be said that other hybrid implementations aren't well implemented and still need some improvement..
Half working drivers and/or badly integrated features are one of the major reasons people turn to Windows instead of Linux.
how can a driver work properly if the base of it gets bombed all the time.
I hereby offer to help review any alternative suggestions you may have without bias or prejudice. I'll need other members to help.
that's great and appreciated, so if you want a history of the previous discussions let me know. There you'll also see that any review from Mauro end up in an accepted improvement, this just proves that other ways are possible too. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
