From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from gateway02.websitewelcome.com ([69.56.176.20]) by www.linuxtv.org with smtp (Exim 4.63) (envelope-from ) id 1KaD8T-0000kX-Uw for linux-dvb@linuxtv.org; Mon, 01 Sep 2008 19:24:18 +0200 Received: from [77.109.104.26] (port=60990 helo=[192.168.1.3]) by gator143.hostgator.com with esmtpa (Exim 4.68) (envelope-from ) id 1KaD8M-0004Ff-Cr for linux-dvb@linuxtv.org; Mon, 01 Sep 2008 12:24:10 -0500 Message-ID: <48BC253A.7050409@kipdola.com> Date: Mon, 01 Sep 2008 19:24:10 +0200 From: Jelle De Loecker MIME-Version: 1.0 To: linux-dvb References: <200809010005.28716.liplianin@tut.by> <48BB0FE7.2010109@linuxtv.org> In-Reply-To: Subject: Re: [linux-dvb] DVB-S2 / Multiproto and future modulation support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1291797030==" Mime-version: 1.0 Sender: linux-dvb-bounces@linuxtv.org Errors-To: linux-dvb-bounces+mchehab=infradead.org@linuxtv.org List-ID: This is a multi-part message in MIME format. --===============1291797030== Content-Type: multipart/alternative; boundary="------------020904050606010206030102" This is a multi-part message in MIME format. --------------020904050606010206030102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You said everything that needed to be said, I agree with you 100 % I vote for the merging of multiproto. /Met vriendelijke groeten,/ *Jelle De Loecker* Kipdola Studios - Tomberg VDR User schreef: > After some consideration, I can not ack this new api proposal. I > believe a lot of the support for it is based in people not knowing the > current state of multiproto and thinking this might be the only path > to new needed drivers. It hasn't helped that there has been some > misinformation spread such as the binary compatibility and so on. > There is a current pull request for multiproto right now and if done, > drivers could start being developed right now. In the end that's what > matters to users, especially those of us who've been patiently waiting > several months or even years. > > To my knowledge the multiproto api is very robust and can be easily > updated to accommodate new modulations, etc. From a technical > standpoint, I can't justify disregarding all the work thats been done > on multiproto, especially when it's finally ready to go. In Mauro's > own response to the pull request, he admits the multiproto code is > complete. Unless someone can provide legitimate reasons why we should > wait for yet another api to be written when multiproto is (finally) > ready to be pulled now, I'm afraid I can't support the idea. > > People have been waiting to move forward with a new api for a long > time and it seems we can with multiproto right now, today. I don't > agree that makes a very strong case of too little, too late. Whether > it's openly admitted or not, I think we're mostly all aware that there > is some personal politics involved in this as well, which is > unfortunate. Hopefully people will be mature enough to put that aside > and do what's best for us, the linux dvb user base, as a whole. After > learning that multiproto is ready and there's no technical reason > against it, I wonder how many people still choose to wait for another > api to be written..? > > Best regards guys! > --------------020904050606010206030102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You said everything that needed to be said, I agree with you 100 %

I vote for the merging of multiproto.

Met vriendelijke groeten,

Jelle De Loecker
Kipdola Studios - Tomberg


VDR User schreef: 
After some consideration, I can not ack this new api proposal.  I
believe a lot of the support for it is based in people not knowing the
current state of multiproto and thinking this might be the only path
to new needed drivers.  It hasn't helped that there has been some
misinformation spread such as the binary compatibility and so on.
There is a current pull request for multiproto right now and if done,
drivers could start being developed right now.  In the end that's what
matters to users, especially those of us who've been patiently waiting
several months or even years.

To my knowledge the multiproto api is very robust and can be easily
updated to accommodate new modulations, etc. From a technical
standpoint, I can't justify disregarding all the work thats been done
on multiproto, especially when it's finally ready to go.  In Mauro's
own response to the pull request, he admits the multiproto code is
complete.  Unless someone can provide legitimate reasons why we should
wait for yet another api to be written when multiproto is (finally)
ready to be pulled now, I'm afraid I can't support the idea.

People have been waiting to move forward with a new api for a long
time and it seems we can with multiproto right now, today.  I don't
agree that makes a very strong case of too little, too late.  Whether
it's openly admitted or not, I think we're mostly all aware that there
is some personal politics involved in this as well, which is
unfortunate.  Hopefully people will be mature enough to put that aside
and do what's best for us, the linux dvb user base, as a whole.  After
learning that multiproto is ready and there's no technical reason
against it, I wonder how many people still choose to wait for another
api to be written..?

Best regards guys!
--------------020904050606010206030102-- --===============1291797030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb --===============1291797030==--