lkml.org 
[lkml]   [2008]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [linux-dvb] Multiproto API/Driver Update
From
Date
On Mon, 2008-09-15 at 01:01 +0400, Manu Abraham wrote:
> Andy,
>
>
> Andy Walls wrote:
>
> > Manu,
> >
> > 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.
>
> To your utter disappointment as i should say, i am not working for any
> vendor, but just get device support out to the community.

Not to my disappointment. I'm glad to hear it. Someone who appears to
have an EE background without corporate bias can be an asset to the
community.


> The jusst.de domain is owned by Julian Scheel who runs Jusst
> Technologies, just happened to offer me hosting for me repositories for
> my work, using full ssh access, so that my workflow is easier.
>
> Not that i have anything to do with jusst.de otherwise. OTOH, i do have
> the patches at kernel.org
>
> Maybe Julian can comment on this to make things more clearer on the
> financial interests.

Then what I perceived was wrong. My apologies.



> > 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.
>
>
> I am not manipulating any timing of multiproto being merged. In fact i
> had been away, for a few months due to certain reasons, that you are
> perfectly aware by now as far as i can understand.

I was aware you were away. For what dates I do not know (I have emails
from you in May 2008). For what reasons, I do not know for sure (nor do
I feel is it my business).



> So the points that
> you raise are quite baseless.

Not entirely, there is a basis for the timing point. The pull requests
seemed to have come in short order when confronted with a competing
proposal. Yet the project had been ongoing for at least over a year (as
far as I can ascertain). Here's a gripe about delays from Jan 2008:
http://www.mail-archive.com/linux-dvb@linuxtv.org/msg28606.html

There seemed to have been no other visible motivation for the pull
requests except competition.



> > 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.
>
> Crap, just read above.

OK, then you do have some high ground. But you also had essentially a
monopoly position and now you have competition. That is not crap.


> > 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.
>
>
> I don't have to do any mud-slinging, just wrote the exact facts out here.

No, you are mud slinging. Let's count the derogatory terms you use in
addressing your competition in the following quote:

"No need for you to break the compliant devices in favour of your
mediocre cards. As i wrote just above, the STB0899 is not the only one
device using the said features. Also i can guarantee that the CX24116
(HVR4000) is the most handicapped DVB-S2 device that you are basing the
DVB-S2 API on: and i can guarantee that what you do will be just be
broken as you have done for other devices in the past."

"Also i do not understand, why you have to make a lot of noise to port
the STB0899 drivers to your crap, when all your cards work as expected
by you with the multiproto tree. I don't see any reason why the STB0899
has to be ported to the handicapped API of yours, handicapping the
STB0899 based devices."


1 mediocre
3 handicap (or variation thereof)
1 crap
2 break (or variation thereof) when referring to competing work
1 noise, when referring to another offer to do work competing work

And that's just part of the email. I'd hate to read when you actually
claim to be mud-slinging.

Regards,
Andy

> Regards,
> Manu




\
 
 \ /
  Last update: 2008-09-15 00:23    [W:0.063 / U:1.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site