Steve, Does this mean you will be working on an alternative to MultiProto? As an HVR4000 user I am following this thread closely as you might imagine.
Ian On 11/1/07, Steven Toth <[EMAIL PROTECTED]> wrote: > > Manu Abraham wrote: > > Steven Toth wrote: > >> Johannes Stezenbach wrote: > >>> Hi, > >>> > >>> On Tue, Oct 30, 2007, Manu Abraham wrote: > >>> > >>>> Johannes Stezenbach wrote: > >>>> > >>>>> three weeks have passed since Steve expressed his > >>>>> discomfort with the HVR4000 merge being blocked > >>>>> waiting for multiproto. > >>>>> > >>>> Before i state anything, Current DVB-S2 API status: > >>>> > >>> [snip] > >>> > >>> Thanks, that's useful. > >>> > >>> > >> Yes. > >> > >>>>> Can you give us a time frame for when the multiproto > >>>>> merge will happen? > >>>>> > >>>>> Or, alternatively, can we split multiproto into > >>>>> two repositories, one with API + dvb-core changes > >>>>> and one (on top of it) with the STB0899 driver? > >>>>> > >>>> It can be either way, which one of the following do you think is > >>>> better in your view ? > >>>> > >>>> (1) DVB-S2 API partly merged now and the rest of the S2 API later. > >>>> (2) Complete event list update and VCM and merge that also alongwith. > >>>> > >>>> in either case it can be with or without the STB0899 driver. > >>>> > >>>> What do you think ? > >>>> > >>> I'd prefer to address the remaining API issues first, however > >>> what I primarily want to avoid is that Steve rewrites the > >>> HVR4000 driver to a competing API proposal due to > >>> frustration with the lack of progress. > >>> > >>> > >> Agreed. > >> > >>> IMHO there should be a clear path of actions for Steve > >>> (or whoever else wants to help) to do that would allow merging > >>> the HVR4000 driver. I.e. instead of having to wait for some > >>> event beyond his control there should be a checklist, and > >>> the merge can happen when all items are resolved. > >>> > >>> Or something like that. Preferably Steve would comment > >>> how he'd like to go forward. > >>> > >>> > >> If these are new API's then I suspect the HVR4000 doesn't use them. I > >> would agree it makes sense to define them, but depending on their focus > >> they may not need to be implemented and should not be considered a > >> roadblock to an alpha release. > >> > >> If they don't impact core functionality then I see no reason why this > >> cannot be defined now, but implement (and refined) later during the > test > >> cycle. (I'm expecting testing to be a very long process, because we'll > >> need to encourage the VDR/MythTV/Other applications groups to begin > >> integration). > >> > >> I am a realist. I don't expect the first tree will be perfect. I am > >> expecting some change. I am expecting apps devs/testers to find bugs > and > >> problems which will cause us to rethink some parts of the multiproto > >> core and it's S2 drivers. > >> > >> No doubt the VDR and MythTV folks will also have something to say and > >> that may impact the API also. We need to pay respect to the opinions of > >> the applications developers. > >> > >> I don't think the first release needs to be perfect. > >> > >> I think if the current API is good enough to support the needs of > >> Myth/VDR then that's something we can start with. Release early, > release > >> often. > > > > > > It is not how the APi is good enough to support the needs of MythTV or > VDR, > > but how the API can be considered as a guide for the application > developers > > to understand how to talk to a DVB-S2 device > > > > > >> Manu, this is your patch and I respect your work, how would you suggest > >> we proceed? > >> > > > > There does exist a ported version of VDR to the new API. The current > situation > > is that the S2 devices cannot be tuned to certain frequencies because of > the > > use of Backward compatible modes, ie the API, nor the drivers currently > do > > support them. > > > > Give application developers a chance to mess up stating that the API is > out, > > eventually what will happen is: example look at people crying out on > > mythtv issues with regards to DVB devices. I have had quite some > experiences > > trying to make application developers understand what they do wrong. > > > > I am waiting to hear from other developers as well, whether they would > like to > > do whether to do > > > > (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later. > > (2) DVB-S2 API what it needs to tune to all the transponders at least > > > > Look, this is not the question of the HVR4000 or the STB0899 alone, it > will affect > > all future devices. As Johannes said, what goes into the API (user ABI) > is permanent, > > it won't change. It is something that will be set in stone as opposed to > the driver > > internal API. (The driver API we can change, but not the ABI) What we > are looking at > > is the API-ABI > > > > Let me cite certain examples of such large scale screwups where people > are stuck: > > > > > > You've miss-interpreted my comments. > > I suggested that the API should be defined, but not necessarily > implemented. I was suggesting that we define enough API to generate a > test tree and make some progress. Supporting your earlier statement, I > suggested that the small amount of unimplemented API (which you > suggested was inconsequential) could be implemented while other > developers were testing the core TV functionality. > > I.e. This becomes a group effort, not a Manu effort. > > I never suggested the test tree would get merged, in fact I went out of > my way to suggest that the process of testing would likely raise various > design issues and/or bugs. I clearly outlined that I'm a realist and I > expected this testing phase to cause change. > > I thought I'd made myself clear. > > I ended my previous email respectfully and repeated Linus's mantra. I > was assuming your response would be positive. > > Instead you've launched into a patronizing tirade and none of this > ingratiates you with the other developers, it only stands in the way of > progress and demonstrates the attitude we've witnessed over the last > 12-18 months re: multiproto. > > I don't think I have anything else to say on the subject of multiproto, > until you see fit to deliver publically your 'marvelous multiproto > invention - all things under one roof', no doubt to the sound of > trumpets, gasps and country wide applause. > > I'm wasting my time here. > > - Steve > > > > > _______________________________________________ > linux-dvb mailing list > linux-dvb@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb >
_______________________________________________ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
