Johannes Stezenbach wrote: > On Fri, Oct 12, 2007 at 11:56:21AM +0400, Manu Abraham wrote: >> Johannes Stezenbach wrote: >>> On Fri, Oct 12, 2007, Manu Abraham wrote: >>>> Johannes Stezenbach wrote: >>>>> Does that mean that Manu has no intentions to get >>>>> his multiproto API changes merged? >>>> It will be merged >>> When? Why hasn't it been merged months ago when HVR4000 worked? >> HVR4000 was struggling even recently howto handle pilots, because it >> had a hard time trying to figure out how pilots worked. Eventually, the >> implementation from the STB0899 had to be copied to the same, for it >> to work. The reason being CX24116 being mostly RE'd, AFAIH. > > Drivers will always have bugs, so what? The hg log suggests that > the pilots should also be in the API, but Steve had to wait for > you to deliver an updated API and thus fixed it internally. eh ? Pilot detection is an internal part of the driver, not part of the API. > Within the scope of testing Steve could do the driver was > presumably ready months ago -- I take Steve's word on this. > >>>>> (If so, then wtf was the point of doing them and keep >>>>> everyone waiting? But I guess the "DVB API update" thread >>>>> meant he isn't happy with it anymore.)) >>>> As i wrote, there are more things in the S2 specification, also >>>> currently stuff like proper statistics cannot be done for example >>> As I tried to tell you in one of my replies in the "DVB API update" >>> thread statistics is totally independent of DVB-S2. And the >>> "more things" were not spelled out in detail by you -- and >>> why don't you just fix the API if you know something is missing, >>> instead of saying "something's missing, can't merge yet"? >> Please, Just look at the changesets for the same. > > I don't get it -- one mail you say something's missing, > next mail you say already done. > maybe you want to read selectively >>> I just can't understand why you were dragging this out so long, >>> usually I would expect the desire of any developer is to get >>> the code merged ASAP. With a working HVR4000 driver you could've >> FYI, the STB0899 driver is much older than the HVR4000 driver, it has >> been delayed because of >> >> 1) too much noise on the ML (you had bit much to do with it) >> 2) The feedback that resulted from the discussions on the ML, were >> not sufficient for a complete API, eventually STM chipped in, was a >> lot of struggle at my side too. > > Ugh -- the monster thread in May 2006 got so large because > _you_ didn't believe me when I said that his API doesn't match > my understanding of the DVB-S2 spec, and you were unable to > explain to me how it works. So we needed to go through the > spec together trying to figure out how it works. In the end > I concluded the only sane to proceed is to finish writing > a driver to find out if the API _really_ works, and to fix > any API bugs you'd might encounter during driver implementation. > > And now you acknowledge that this was right, and you even > had to ask STM for help. I had go that way, because there was so much confusion added by you into it. > > So I really don't understand your repeated accusations that > I create "too much noise" or "unneccessary discussions". > > >>> got the API and dvb-core changes merged months ago -- which would've >>> allowed you to merge the STB0899 driver in CONFIG_EXPERIMENTAL >>> status to expose it to a wider audience if you'd wanted to. >> Your earlier statements resulted thus: >> >> * go experimental >> * no experimental >> * go experimental >> >> Looks like some square wave function. Are harmonics expected ? > > Here's a little trick question for you: > Does CONFIG_EXPERIMENTAL apply to APIs visible to userspace? > >>> Instead you seem to have the desire to work on your private branch >>> forever, adding patch upon patch to make it as big and important >>> as possible. >> Can you please point to the changesets which cause you to mention >> "adding patch upon patch to make it as big and important as possible" ? >> If you can't point that, it is fairly evident that you are blindly accusing me >> and thereby blurting nonsense and sparking politics. > > Just a few lines above you said: "As i wrote, there are more things > in the S2 specification, also currently stuff like proper statistics > cannot be done for example". And see the "DVB API update" thread. > > Now you play the "what I say is irrelevant, only changesets count" > game, and hurl the P-word at me once more. Thanks. You accused me by stating: "adding patch upon patch to make it as big and important as possible." I asked you to show this in the changeset. Now you fail to do so and try to trick/confuse people. >>> Any not caring at all that you block Steve's work >>> as a consequence. >> hmm.. accusations again. ATM, Steve was/is prejudiced because of something >> else. > > What? Please elaborate. Please read his reply to Herman. >>> I asked you for your plans in this thread but I didn't get an answer. >> I had mentioned the same earlier (not in this thread), maybe you missed >> those mails or that you like to read selectively. >> >> The basic idea is that STM contributed to many stuff, including comments >> as how things should be done. Maybe you are not aware how you work >> with a vendor for their devices and or when you have taken support from >> them, you need their final approval. >> >> Thus, before anything is done, i need to get a confirmation from STM as >> well. I have asked STM as well, please read the inlined mail. > > STM's contributions are welcome, but we cannot allow them to block > the merge of the HVR4000 driver. If they (or you) think the STB0899 > driver isn't ready, then your changes should be split so that the > API and dvb-core changes can be merged with HVR4000 without dragging > STB0899 into the merge. > >>> Anyway, I don't know what has been said on irc and I can't >>> be bothered to read the irc logs. I really don't care if the DVB-S2 >>> API is done one way or the other, if you can't cooperate with Steve >>> then you have to compete with him. IMHO the first one to have a fully >>> working API + driver ready for merging wins. That's what I vote for. >> HVR4000 specific S2 API ? > > Huh? > > >>> The requirements to make it mergable are still the same >>> as in Nov. 2005 when the DVB-S2 API was discussed first: >>> - don't break backwards compat >>> - add complete support for all DVB-S2 features, or at least >>> allow missing features be added later in a backwards compatible way >>> - don't be completely ugly (like the Reelbox hack) >>> - don't repeat past mistakes and design it to allow easier backwards >>> compatible extensions in the future (like e.g. for DVB-H) >> Please do check in the tree whether you still have anything to NACK. If it is >> ok, i will have another round of cleanups. > > I won't do it while it's in the "wait for STM or whatever" stage, I would > maybe do it when you post your "it's ready for merge, please review" mail. > > But I'll also wait what Steve will be doing, and what others say. > Currently I feel I'd be riding a dead horse if I'd put any work > into reviewing your code. > > > Johannes > Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
