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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
