Re: [linux-dvb] Multiproto API/Driver Update

From: Andy Walls
Date: Mon Sep 15 2008 - 19:11:14 EST


On Mon, 2008-09-15 at 07:50 +0200, Julian Scheel wrote:
> Andy,
>
> just to clarify things a bit I'll give a short statement now.
>
> Andy Walls schrieb:
> > Though I can't read much German, after looking at the jusst.de website I
> > can't help but think that you as well have financial interests driving
> > your actions. If so, then your statements display quite a bit of
> > hypocrisy.
> >
> The role of jusst technologies in the whole multiproto story is as
> following:
> The time when DVB-S2 came up this was of course of major interest for
> jusst technologies, so we searched for people working on drivers. At
> that not many people did seem to care about this stuff - but Manu did.
> So we got in contact and tried to help him as much as we can, which
> included making up connections to KNC1 for technical questions and
> datasheets, provide a KNC1 testing board and later then give free
> web/codespace to Manu.

Julian

First let me acknowledge jusst technologies contribution. It seems
generous. Thank you for clarifying.


> Furthermore we of course did lots of testing of multiproto. But never we
> did pay Manu for any of this work.
> Reading that you should recognize that there can't be much financial
> interests for Manu.

Manu clarified this.



> Seeing that you impute hyprocrisy to Manu due to "facts" you don't have
> proven in any way makes me a bit contemplative.

This is where you misrepresent my words: "I can't help but think..." is
phrase that doesn't not imply certainty but indicates my *perception*.
I did not assert this as fact, as the following statement started "If
so, ..." which is a conditional clause.

Maybe this subtlety is lost in translation.




> I don't like being
> political when talking about technical terms (which linuxtv in first
> place should be about imho) - anyway this one time I will give a
> somewhat political statement, too.
> All you guys who are blaming Manu to do some wrong or bad stuff,

No. It was my ill researched, emotive response to Manu attacking
someone.


> what is
> your point?


My point was to suggest to Manu that there were more productive ways to
further his cause than to throw stones at people.

Manu, who you support, BTW, was the one who initially introduced
allegations of a developer introducing corporate politics.


> - I see you searching quote where Manu did talk in a
> somewhat unpolite manner

There was no searching involved. That quote was text I cut out in my
initial response. I reinserted it to refute Manu's denial.



> just to blame him of being the wrong person
> introducing a new API?


> - I have no interest in doing the same quoting
> with your postings or the so called competitors postings, but I'd bed I
> could quote almost any of you in a not less distracting manner than you
> like to do with Manu.
> > Manipulating (i.e. stalling) the timing of Multiproto being merged into
> > the v4l-dvb tree or kernel, for you or your employer's gain, would be
> > little different from the motivations you allege Steve of having.
> >
> > Since the major gripe I'm reading on the list "is that multiproto has
> > taken too long" and since it seems to me the only thing that shook it
> > loose was a competing proposal, please save the venom for when you
> > actually have some clear moral high-ground to stand on. I don't see it
> > from here.
> >
> Using "taking too long" as an argument against an API proposal is really
> interesting. What did you expect? - A quick shot which is not well
> thought about wouldn't have be a good thing for anyone.
> I'm absolutely fine if anyone would came up with real technical
> arguments, but reading many postings so far I couldn't find much of such
> statements.

Let me help you. Please read these postings of mine and give me your
honest feedback:

http://linuxtv.org/pipermail/linux-dvb/2008-September/028651.html
http://linuxtv.org/pipermail/linux-dvb/2008-September/028727.html


Are these the emails of someone who doesn't care about the technical
aspects?

I didn't post them to the LKML because I didn't think the issue needed
expand to there.



> > As for the technical superiority of either API proposal; that probably
> > just doesn't matter. I've seen policy/political decisions force
> > suboptimal technical solutions at work time and time again. If you
> > really believe you have a superior product technically; then perhaps you
> > should work to make it superior politically as well. Mud-slinging can't
> > be a good long term strategy toward that end.
> >
> To be political again: Thank you for blaming jusst being not interested
> in proper technical solutions. What makes you thinking of this?

I said no such thing. The implication was that politics often
(tragically IMO) often weigh heavier than technical merit in making
decision. This was my recommendation to Manu not to neglect that
aspect, lest he get shortchanged. I was trying to help/advise. Maybe
that was not clear.



> - Just
> the fact that you recognize jusst as a commercial company? Very interesting.


> I really have a feeling that many people here are mostly interested in
> making politics instead of thinking about technical solutions which
> makes all this a horrible topic

Then tell Manu not to initiate with unkind allegations, and he won't
evoke the same in return. Again, the horror of the whole mess is what
moved me to respond.

I couldn't give $0.02 about the new API. I don't think I'll ever need
it myself. That's a selfish US user's perspective, but it also
validates my motivation for responding: to try and stop the animosity.


> for all that people who are interested
> in a working solution (which Manu has proven to deliver) - mainly the users.
>
> So far this is my statement (in representation for jusst technologies)
> for the moment.

I'm sorry if you feel I've somehow injured the name of jusst
technologies. That certainly wasn't any intention of mine.

Regards,
Andy

> Best regards,
> Julian
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/