[linux-dvb] [RFC] Reviewed development procedures DVBMaintainer
mrechberger at gmail.com
Fri Mar 9 15:34:42 CET 2007
On 3/9/07, Steven Toth <stoth at hauppauge.com> 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.
> 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
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
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
* 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.
More information about the linux-dvb