Re: [linux-dvb] Future of Multiproto
Oliver Endriss wrote: Marcel Siegert wrote: can everybody _please_ stop this unnessessary discussion? Full ack! I'm really tired reading these garbage threads. @all, I suggest the following: 1a Review the API extensions (dvb_frontend.h). 1b Commit them. 2a Review dvb_core modifications. 2b Commit them. 3 Commit drivers when they are ready for inclusion. Will appreciate if you will do a review on this tree. http://jusst.de/hg/multiproto/ The tree is not very clean though, with regards to CodingStyle etc. If it looks fine, i will do the cleanups. Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Oliver Endriss wrote: Manu Abraham wrote: Oliver Endriss wrote: @all, I suggest the following: 1a Review the API extensions (dvb_frontend.h). 1b Commit them. 2a Review dvb_core modifications. 2b Commit them. 3 Commit drivers when they are ready for inclusion. Will appreciate if you will do a review on this tree. http://jusst.de/hg/multiproto/ The tree is not very clean though, with regards to CodingStyle etc. If it looks fine, i will do the cleanups. I'll try to find some time this week. Thanks Regards, Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Marcel Siegert wrote: can everybody _please_ stop this unnessessary discussion? Full ack! I'm really tired reading these garbage threads. @all, I suggest the following: 1a Review the API extensions (dvb_frontend.h). 1b Commit them. 2a Review dvb_core modifications. 2b Commit them. 3 Commit drivers when they are ready for inclusion. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
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. (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 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. 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 ? 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. 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. 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. Original Message Subject: STB0899 driver and mixed results Date: Mon, 08 Oct 2007 16:35:11 +0400 From: Manu Abraham [EMAIL PROTECTED] To: XXX --- snip --- The STB0899 driver is finally getting to shape by now. Currently supported hardware is like this, by the driver here: http://jusst.de/hg/multiproto/ Some cleanups etc pending on it. The entire drivers can be downloaded from this URL: http://jusst.de/hg/multiproto/archive/tip.tar.gz * KNC1 DVB-S2 Plus * KNC1 DVB-S2 OEM (Also known as Satelco DVB-S2) * Technotrend TT S2 3200 * Technisat DVB-S2 Skystar HD The Technisat card, as it seems looks to be the same as that of the Technotrend TT S2 3200 card, except that it has a STB0899 with version C2L. Now i have a question (well, it's a problem that i am facing) It goes like this The KNC1 cards (both) and the Technotrend TT S2 3200 cards tune quite fine, and LOCK is almost immediate, less than half a second (impressive results) i did make a small change, from the case where it selects between MCPC/SCPC config where it uses 2 different clocks, for the MCPC case i changed it from 99 MHz to 90 MHz which makes the tuning quite fast and a bit more reliable (ie no more LOCK failures on the KNC1 and the TT S2 3200 cards) Now, on the Technisat Skystar HD card, there have been mixed results. One person got back stating that performance was real pathetic and LOCK 'ing time took minutes and or sometimes no LOCK's at all. Another person got back stating that he had 90% successful locks with DVB-S and 50% successful locks on DVB-S2 both cases with the Technisat card. --- snip --- Regards, Manu Anyway, I don't know what has been said on irc and I can't be bothered to read the irc
Re: [linux-dvb] Future of Multiproto
Hi, On Fri, Oct 12, 2007, Marcel Siegert wrote: can everybody _please_ stop this unnessessary discussion? When a developer deletes his mercurial repositories and announces he's going to rewrite the code to be independent of multiproto, then IMHO it is _necessary_ to find out why, and how to continue now. I have a vague idea about the state of multiproto now, but now I'm waiting for Steve to comment if he's happy if multiproto would be merged _now_, or if he wants to do something else, and explain what. Anyway, the decisions to make are not mine, I'm just trying to extract the information needed so all the cards are on the table for everyone to see easily. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Marcel Siegert wrote: hi, can everybody _please_ stop this unnessessary discussion? manu, nobody is playing politics in the moment, not johannes, not steven, not anyone else. What was discussed yesterday was that, if you don't do what i write, i'll just take your code nevertheless as it is. maybe sometimes it is hard to understand what people want to say if you have all the bad past in mind. what was said in coherence to your multiproto api change is just as simple as follows: please state if you are ready to merge multiproto to the main repository, whatever way it will take into. steven has got a ready driver, that demonstrated your api is fine and works, you have got your stb0899 driver nearly done, and also beside some small problems due to the device, its also proven working. if there is something missing from dvb-s2 specs that is not needed to actually watch tv, dont take any care on that to prevent multiproto to be merged. we can get rid of _all_ the momentary stupid discussions if you are ready to merge it. I am ready, but waiting for a final acknowledgement, that's what it is. If someone would like to find offending changesets, that can be done in the meantime. If that's done, i will do the cleanups for the same, such that it can go in. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
hi, can everybody _please_ stop this unnessessary discussion? manu, nobody is playing politics in the moment, not johannes, not steven, not anyone else. maybe sometimes it is hard to understand what people want to say if you have all the bad past in mind. what was said in coherence to your multiproto api change is just as simple as follows: please state if you are ready to merge multiproto to the main repository, whatever way it will take into. steven has got a ready driver, that demonstrated your api is fine and works, you have got your stb0899 driver nearly done, and also beside some small problems due to the device, its also proven working. if there is something missing from dvb-s2 specs that is not needed to actually watch tv, dont take any care on that to prevent multiproto to be merged. we can get rid of _all_ the momentary stupid discussions if you are ready to merge it. thus we could go back concentrate developing stuff, merge it, satisfy endusers instead of having to spent all of our time to behave like linuxtv.childhood. HTH marcel ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
hermann pitton wrote: Am Mittwoch, den 10.10.2007, 23:44 +0400 schrieb Manu Abraham: Steven Toth wrote: If there is a defined workflow, this moaning will stop. With the moaning on there will be problems and blindly writing mails based on that, just adds in to the problems at large. Thanks for the feedback. I had some difficulties understanding parts of your email, so I may come back to those pieces later today. One thing that was obvious... I don't understand what you mean about workflow, or why it's a problem, or why defining the workflow will help you, or resolve your concerns/frustrations. Clearly you are referring to how we collect and manage trees under linuxtv.org, but you haven't suggested an alternative method. I did. Maybe you missed it, anyway that is not significant. Will readdress it in a more clear manner Two questions: How do you suggest improve 'workflow'? Let me tell you how problems arise. @ the problem User sends a patch the person who was write access to linuxtv.org/hg/v4l-dvb, takes the patch and applies it. (Please note, this is not personal, this issue results for anyone doing the same job) Now the person who has write access is neither the author/maintainer of the driver/code and has little clue. (it is the nature of any human being), he thinks that i have been doing this, who are you to tell me. In either case whether the patch is good or bad (not talking about the quality of the patch, but that which results in the unnecessary discussions and or talks) Now the actual author/maintainer has issues with the patch whatever it is. Now the argument goes on for a while. In most cases the person who has write access to the repository get's it right (since others tend to shy away for some reason) This is a bad situation where the people who do the real work in fact do get demoralized, also not to mention the long unnecessary discussions. That is the bad side of things and this is what exactly what we are facing Situations like this can be avoided. There is more than one possible way, but there are two possible ways this can work @ Improving the situation Say whoever maintains some code he can be called the maintainer for the same. Well this shouldn't be verbal, as this has proved many times that what's considered verbal, behind the back there are many discussions and we have seen practically how this works. So there needs to be well defined who maintains what, and mainline kernel folks also need to know about it, lest someone should have a doubt and the problematic case is revisited. i would suggest it the same place where the rest of the kernel goes, we shouldn't be doing things in a different way (doing things different attracts different problems from the kernel style development methods, then the situation is different) That said about the thought. Practically it might look like this 1) a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies the (modified or unmodified) patch to the tree (this assumes that the maintainers do have write access to the project base tree) d) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree 2) steps a - b are the same a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies it to the tree that which is meant specific for the code/module that which the patch is sent for. d) he asks whoever is sending patches to apply changes from this tree to the project base tree e) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree The application of changes from the base tree to the patches sent to Linus must be atomic. ie , there shouldn't be any shady deals in between. (The reason being the condition of cherrypicking also doesn't come into the picture as the changes have already been discussed/acknowledged, otherwise it wouldn't exist in that tree in the first place) Now, in either of these cases there will be common code NOTE! * In the case of the common code, the relevant maintainers all must agree for that specific change, without which it might be hard to have that change in. There is one significant advantage to this method, this will
Re: [linux-dvb] Future of Multiproto
Steven Toth wrote: Speaking purely for myself, my involvement with linuxtv varies depending on my other work commitments. For this reason, I do not expect to review every patch which gets created against the various drivers I've ever brought to life. So, Manu's idea doesn't work for me, and I have no idea whether it would work for Mauro (higher up my foodchain). According to the kernel development policy, an author need not be a MAINTAINER. If you do not which to maintain it, you can pass on the maintainership to someone else whom you wish to. It is that simple. One final thought. You would not believe how many individuals and commercial companies have contacted me re: HVR4000 S2 support in Linux. It's an important _missing_ feature. Every device it is the same. It is not the issue with the HVR400 alone, there are other S2 devices as well. Even the S2 features that are in are just partial as well. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
(Corrected a typo) Steven Toth wrote: Speaking purely for myself, my involvement with linuxtv varies depending on my other work commitments. For this reason, I do not expect to review every patch which gets created against the various drivers I've ever brought to life. So, Manu's idea doesn't work for me, and I have no idea whether it would work for Mauro (higher up my foodchain). According to the kernel development policy, an author need not be a MAINTAINER. If you do not wish to maintain it, you can pass on the maintainership to someone else whom you wish to. It is that simple. One final thought. You would not believe how many individuals and commercial companies have contacted me re: HVR4000 S2 support in Linux. It's an important _missing_ feature. Every device it is the same. It is not the issue with the HVR400 alone, there are other S2 devices as well. Even the S2 features that are in are just partial as well. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Steven Toth wrote: hermann pitton wrote: Am Mittwoch, den 10.10.2007, 23:44 +0400 schrieb Manu Abraham: Steven Toth wrote: If there is a defined workflow, this moaning will stop. With the moaning on there will be problems and blindly writing mails based on that, just adds in to the problems at large. Thanks for the feedback. I had some difficulties understanding parts of your email, so I may come back to those pieces later today. One thing that was obvious... I don't understand what you mean about workflow, or why it's a problem, or why defining the workflow will help you, or resolve your concerns/frustrations. Clearly you are referring to how we collect and manage trees under linuxtv.org, but you haven't suggested an alternative method. I did. Maybe you missed it, anyway that is not significant. Will readdress it in a more clear manner Two questions: How do you suggest improve 'workflow'? Let me tell you how problems arise. @ the problem User sends a patch the person who was write access to linuxtv.org/hg/v4l-dvb, takes the patch and applies it. (Please note, this is not personal, this issue results for anyone doing the same job) Now the person who has write access is neither the author/maintainer of the driver/code and has little clue. (it is the nature of any human being), he thinks that i have been doing this, who are you to tell me. In either case whether the patch is good or bad (not talking about the quality of the patch, but that which results in the unnecessary discussions and or talks) Now the actual author/maintainer has issues with the patch whatever it is. Now the argument goes on for a while. In most cases the person who has write access to the repository get's it right (since others tend to shy away for some reason) This is a bad situation where the people who do the real work in fact do get demoralized, also not to mention the long unnecessary discussions. That is the bad side of things and this is what exactly what we are facing Situations like this can be avoided. There is more than one possible way, but there are two possible ways this can work @ Improving the situation Say whoever maintains some code he can be called the maintainer for the same. Well this shouldn't be verbal, as this has proved many times that what's considered verbal, behind the back there are many discussions and we have seen practically how this works. So there needs to be well defined who maintains what, and mainline kernel folks also need to know about it, lest someone should have a doubt and the problematic case is revisited. i would suggest it the same place where the rest of the kernel goes, we shouldn't be doing things in a different way (doing things different attracts different problems from the kernel style development methods, then the situation is different) That said about the thought. Practically it might look like this 1) a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies the (modified or unmodified) patch to the tree (this assumes that the maintainers do have write access to the project base tree) d) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree 2) steps a - b are the same a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies it to the tree that which is meant specific for the code/module that which the patch is sent for. d) he asks whoever is sending patches to apply changes from this tree to the project base tree e) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree The application of changes from the base tree to the patches sent to Linus must be atomic. ie , there shouldn't be any shady deals in between. (The reason being the condition of cherrypicking also doesn't come into the picture as the changes have already been discussed/acknowledged, otherwise it wouldn't exist in that tree in the first place) Now, in either of these cases there will be common code NOTE! * In the case of the common code, the relevant maintainers all must agree for that specific change, without which it might be hard to have that
Re: [linux-dvb] Future of Multiproto
Steven Toth wrote: Hi, After a disappointing multiproto debate on IRC today I've decided to remove the ~stoth/multiproto and ~stoth/HVR4000 trees from linuxtv.org. I no longer support the multiproto patches and I'm seeking alternative ways to deliver the HVR4000 S2 driver to the community. How come putting the tree from jusst.de to linuxtv.org/hg/~user/ is going to help ? I can't understand your arguments that you made on IRC. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Johannes Stezenbach wrote: On Thu, Oct 11, 2007, Steven Toth wrote: After a disappointing multiproto debate on IRC today I've decided to remove the ~stoth/multiproto and ~stoth/HVR4000 trees from linuxtv.org. I no longer support the multiproto patches and I'm seeking alternative ways to deliver the HVR4000 S2 driver to the community. For the time being I am no longer taking emails for HVR4000 related issues, please do not contact me directly about any HVR4000 related source code. All HVR4000 source code I've previously released is licensed under GPL and that does not change, you are welcome to use it within the terms of the license. IRC... Does that mean that Manu has no intentions to get his multiproto API changes merged? It will be merged (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 The CX24116 doesn't do those so probably doesn't matter, for that driver. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Georg Acher wrote: On Thu, Oct 11, 2007 at 05:11:24PM -0400, Steven Toth wrote: Anyway, sadly, I had to drop support for the HVR4000 via your patches and I'll have to find a way to reimplement support via another mechanism. Almost a year ago I've used a very early stage of your 24116 driver as the basis for the S2 tuner of the Reelbox (the current driver can be obtained from their SVN). Since I was already sceptical about the DVB-API replication with multiproto, I used a pragmatic hack: The modulation (8PSK and S2-QPSK) and the rolloff is encoded in the upper 16 bit of the FEC value (usually 0). The new S2 FECs are appended after FEC_AUTO. So the API is absolutely backward compatible, in fact we are using kernel 2.6.11 on the reelbox. The only drawback is that the frontend type cannot be changed (still FE_QPSK) and the S2 capability detection must be done by the string DVB-S2 in the tuner name ;-) Not very clean, but we are working in a known environment... Thanks for the feedback, useful to know. I know other people are doing similar things with the 24116 in commercial CE devices, rather than use multiproto also. They have launched products with success. Regards, Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
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? (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? 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 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. 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. Any not caring at all that you block Steve's work as a consequence. I asked you for your plans in this thread but I didn't get an answer. 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. 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) Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Manu Abraham wrote: Steven, Steven Toth wrote: Johannes / Manu, I'm actually pretty sad about the whole situation. The HVR4000 has been done for over a year, probably much more. Support for this product in the main v4l-dvb repository is stuck behind the multiproto tree, and that's going nowhere. People have been using the HVR4000 and multiproto patches with success, although more widespread thorough testing is always a good thing. Manu, First of all, as a backgrounder, i am no more interested in the politics that which Johannes is fostering as of late. (Removed CC) That said, i do respect Johannes for what he had done in the past, but i am against his policies, ideas and concepts that he has been fostering and cherishing as of late. I will explain why, too. I've pinged and pushed you on a number of occasions to publish an updated tree via hg on linuxtv and for various political reasons this has never happened. I think you made yourself pretty clear via private communications, and via the public DVB API thread.Without re-visiting (or-reigniting) those flames and bad feelings, I think it's clear to me that the future of multiproto being maintained and managed in the linuxtv/hg tree is not going to happen. (Addressing your question on the DVB API thread) The DVB API thread is in the light that the broken things in the API should be fixed. (Some people like to state that those aren't broken) Well, i am not going to use the broken stuff and hence the thread. Now you might be interested to do that, because the cx24116 blindly does that, but as i can see the issues, i am not blindly following what someone states. (Addressing your comment on tree location) when you mean linuxtv/hg tree, there is just only one tree which is called thus http://linuxtv.org/hg/v4l-dvb/ Do you have write access to the repository ? Now, only one single person has access to this tree, so obviously you can't develop in that tree. What you mean to say linuxtv.org/hg, i believe you mean individual developer repositories such as ~stoth/ ~manu/ What difference does it make, if the tree is there elsewhere ? (what advantage does it get you other than you are allowed to have some space for storage at linuxtv.org) In fact having a tree elsewhere makes it easy for tree maintenance. Ok, that said you might suggest, still one should put all their code at linuxtv.org, for that community warmth. This can happen of course, but i have my requests also if that needs to be done, the current workflow needs to be changed. Please feel free to address that thread which exists on the v4l-dvb-maintainer ML, as it was discussed earlier as what is wrong with the workflow as it is, in case you would like to address them. (Basically i don't like those people who steal credits and or people wanking into code that which others do maintain and thus making it broken. Johannes earlier said slap such people, but these days he states that they do for your good. I don't see how that is good except that it brings me in larger headaches. True though it is good for person who is watching the spectacular events) Currently, there is no workflow defined. Right now the concept is, i take your code and i do whatever i want with it. I don't agree to that workflow. This is NOT the OSS philosophy I've offered to help by performing the merge, organizing testing and pushing the work to conclusion (final merge), but that doesn't appease you. I'm not writing this email from spite, I'm simply trying to help you, me and the rest of the community. But, either you have different plans for the patches or you'll give me the OK - here in this thread - to take your patches and begin working on them freely via linuxtv.org/hg (On your statement of a merge) A merge should happen when things are considered stable. At least as far as i can say, it needs some more efforts from my side. I am not for merging something that which needs more work and tests (Anyone who thinks different is in fact creating politics, why ? Generally we have the idea that release when done an not before is the general OSS philosophy. Now why is some people like Johannes creating a politics, whenever he get's the chance ?) First fix your code, then you merge, this is on a general note. if you see such merges/attitudes have only led to a rise of the largely broken code and or drivers. This attitude has to change, merge should happen on complete stuff. (On your statement, of me giving you Ok to do whatever you feel like) This is exactly what anyone would detest. This brings in just broken code/concepts only. Also this does mean that i have stopped working on it and thrown it away. Why is it that you think thus, i don't understand. Unless this happens, I repeat, I cannot see a future where the multiproto patches will be merged
Re: [linux-dvb] Future of Multiproto
Markus Rechberger wrote: Manu Abraham wrote: Steven, Steven Toth wrote: Johannes / Manu, I'm actually pretty sad about the whole situation. The HVR4000 has been done for over a year, probably much more. Support for this product in the main v4l-dvb repository is stuck behind the multiproto tree, and that's going nowhere. People have been using the HVR4000 and multiproto patches with success, although more widespread thorough testing is always a good thing. Manu, First of all, as a backgrounder, i am no more interested in the politics that which Johannes is fostering as of late. (Removed CC) That said, i do respect Johannes for what he had done in the past, but i am against his policies, ideas and concepts that he has been fostering and cherishing as of late. I will explain why, too. I've pinged and pushed you on a number of occasions to publish an updated tree via hg on linuxtv and for various political reasons this has never happened. I think you made yourself pretty clear via private communications, and via the public DVB API thread.Without re-visiting (or-reigniting) those flames and bad feelings, I think it's clear to me that the future of multiproto being maintained and managed in the linuxtv/hg tree is not going to happen. (Addressing your question on the DVB API thread) The DVB API thread is in the light that the broken things in the API should be fixed. (Some people like to state that those aren't broken) Well, i am not going to use the broken stuff and hence the thread. Now you might be interested to do that, because the cx24116 blindly does that, but as i can see the issues, i am not blindly following what someone states. (Addressing your comment on tree location) when you mean linuxtv/hg tree, there is just only one tree which is called thus http://linuxtv.org/hg/v4l-dvb/ Do you have write access to the repository ? Now, only one single person has access to this tree, so obviously you can't develop in that tree. What you mean to say linuxtv.org/hg, i believe you mean individual developer repositories such as ~stoth/ ~manu/ What difference does it make, if the tree is there elsewhere ? (what advantage does it get you other than you are allowed to have some space for storage at linuxtv.org) In fact having a tree elsewhere makes it easy for tree maintenance. Ok, that said you might suggest, still one should put all their code at linuxtv.org, for that community warmth. This can happen of course, but i have my requests also if that needs to be done, the current workflow needs to be changed. Please feel free to address that thread which exists on the v4l-dvb-maintainer ML, as it was discussed earlier as what is wrong with the workflow as it is, in case you would like to address them. (Basically i don't like those people who steal credits and or people wanking into code that which others do maintain and thus making it broken. Johannes earlier said slap such people, but these days he states that they do for your good. I don't see how that is good except that it brings me in larger headaches. True though it is good for person who is watching the spectacular events) Currently, there is no workflow defined. Right now the concept is, i take your code and i do whatever i want with it. I don't agree to that workflow. This is NOT the OSS philosophy I've offered to help by performing the merge, organizing testing and pushing the work to conclusion (final merge), but that doesn't appease you. I'm not writing this email from spite, I'm simply trying to help you, me and the rest of the community. But, either you have different plans for the patches or you'll give me the OK - here in this thread - to take your patches and begin working on them freely via linuxtv.org/hg (On your statement of a merge) A merge should happen when things are considered stable. At least as far as i can say, it needs some more efforts from my side. I am not for merging something that which needs more work and tests (Anyone who thinks different is in fact creating politics, why ? Generally we have the idea that release when done an not before is the general OSS philosophy. Now why is some people like Johannes creating a politics, whenever he get's the chance ?) First fix your code, then you merge, this is on a general note. if you see such merges/attitudes have only led to a rise of the largely broken code and or drivers. This attitude has to change, merge should happen on complete stuff. (On your statement, of me giving you Ok to do whatever you feel like) This is exactly what anyone would detest. This brings in just broken code/concepts only. Also this does mean that i have stopped working on it and thrown it away. Why is it that you think thus, i don't understand. Unless this happens, I
Re: [linux-dvb] Future of Multiproto
Steven Toth wrote: If there is a defined workflow, this moaning will stop. With the moaning on there will be problems and blindly writing mails based on that, just adds in to the problems at large. Thanks for the feedback. I had some difficulties understanding parts of your email, so I may come back to those pieces later today. One thing that was obvious... I don't understand what you mean about workflow, or why it's a problem, or why defining the workflow will help you, or resolve your concerns/frustrations. Clearly you are referring to how we collect and manage trees under linuxtv.org, but you haven't suggested an alternative method. I did. Maybe you missed it, anyway that is not significant. Will readdress it in a more clear manner Two questions: How do you suggest improve 'workflow'? Let me tell you how problems arise. @ the problem User sends a patch the person who was write access to linuxtv.org/hg/v4l-dvb, takes the patch and applies it. (Please note, this is not personal, this issue results for anyone doing the same job) Now the person who has write access is neither the author/maintainer of the driver/code and has little clue. (it is the nature of any human being), he thinks that i have been doing this, who are you to tell me. In either case whether the patch is good or bad (not talking about the quality of the patch, but that which results in the unnecessary discussions and or talks) Now the actual author/maintainer has issues with the patch whatever it is. Now the argument goes on for a while. In most cases the person who has write access to the repository get's it right (since others tend to shy away for some reason) This is a bad situation where the people who do the real work in fact do get demoralized, also not to mention the long unnecessary discussions. That is the bad side of things and this is what exactly what we are facing Situations like this can be avoided. There is more than one possible way, but there are two possible ways this can work @ Improving the situation Say whoever maintains some code he can be called the maintainer for the same. Well this shouldn't be verbal, as this has proved many times that what's considered verbal, behind the back there are many discussions and we have seen practically how this works. So there needs to be well defined who maintains what, and mainline kernel folks also need to know about it, lest someone should have a doubt and the problematic case is revisited. i would suggest it the same place where the rest of the kernel goes, we shouldn't be doing things in a different way (doing things different attracts different problems from the kernel style development methods, then the situation is different) That said about the thought. Practically it might look like this 1) a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies the (modified or unmodified) patch to the tree (this assumes that the maintainers do have write access to the project base tree) d) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree 2) steps a - b are the same a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies it to the tree that which is meant specific for the code/module that which the patch is sent for. d) he asks whoever is sending patches to apply changes from this tree to the project base tree e) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree The application of changes from the base tree to the patches sent to Linus must be atomic. ie , there shouldn't be any shady deals in between. (The reason being the condition of cherrypicking also doesn't come into the picture as the changes have already been discussed/acknowledged, otherwise it wouldn't exist in that tree in the first place) Now, in either of these cases there will be common code NOTE! * In the case of the common code, the relevant maintainers all must agree for that specific change, without which it might be hard to have that change in. There is one significant advantage to this method, this will keep all the relevant people involved, rather than avoiding them, this improves things overall. The current method is to avoid people and a loose method where nothing is defined and confusion
Re: [linux-dvb] Future of Multiproto
Am Mittwoch, den 10.10.2007, 23:44 +0400 schrieb Manu Abraham: Steven Toth wrote: If there is a defined workflow, this moaning will stop. With the moaning on there will be problems and blindly writing mails based on that, just adds in to the problems at large. Thanks for the feedback. I had some difficulties understanding parts of your email, so I may come back to those pieces later today. One thing that was obvious... I don't understand what you mean about workflow, or why it's a problem, or why defining the workflow will help you, or resolve your concerns/frustrations. Clearly you are referring to how we collect and manage trees under linuxtv.org, but you haven't suggested an alternative method. I did. Maybe you missed it, anyway that is not significant. Will readdress it in a more clear manner Two questions: How do you suggest improve 'workflow'? Let me tell you how problems arise. @ the problem User sends a patch the person who was write access to linuxtv.org/hg/v4l-dvb, takes the patch and applies it. (Please note, this is not personal, this issue results for anyone doing the same job) Now the person who has write access is neither the author/maintainer of the driver/code and has little clue. (it is the nature of any human being), he thinks that i have been doing this, who are you to tell me. In either case whether the patch is good or bad (not talking about the quality of the patch, but that which results in the unnecessary discussions and or talks) Now the actual author/maintainer has issues with the patch whatever it is. Now the argument goes on for a while. In most cases the person who has write access to the repository get's it right (since others tend to shy away for some reason) This is a bad situation where the people who do the real work in fact do get demoralized, also not to mention the long unnecessary discussions. That is the bad side of things and this is what exactly what we are facing Situations like this can be avoided. There is more than one possible way, but there are two possible ways this can work @ Improving the situation Say whoever maintains some code he can be called the maintainer for the same. Well this shouldn't be verbal, as this has proved many times that what's considered verbal, behind the back there are many discussions and we have seen practically how this works. So there needs to be well defined who maintains what, and mainline kernel folks also need to know about it, lest someone should have a doubt and the problematic case is revisited. i would suggest it the same place where the rest of the kernel goes, we shouldn't be doing things in a different way (doing things different attracts different problems from the kernel style development methods, then the situation is different) That said about the thought. Practically it might look like this 1) a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies the (modified or unmodified) patch to the tree (this assumes that the maintainers do have write access to the project base tree) d) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree 2) steps a - b are the same a) the person who has a patch sends a patch. (normally people lookup MAINTAINERS whom to address the patch, some people send it to the Mailing List) b) the relevant maintainer picks it up, comments on it or cherrypick or whatever it needs to be done c) the relevant maintainer applies it to the tree that which is meant specific for the code/module that which the patch is sent for. d) he asks whoever is sending patches to apply changes from this tree to the project base tree e) from this tree, the person responsible for sending patches to Linus can pick up the patches from the project base tree The application of changes from the base tree to the patches sent to Linus must be atomic. ie , there shouldn't be any shady deals in between. (The reason being the condition of cherrypicking also doesn't come into the picture as the changes have already been discussed/acknowledged, otherwise it wouldn't exist in that tree in the first place) Now, in either of these cases there will be common code NOTE! * In the case of the common code, the relevant maintainers all must agree for that specific change, without which it might be hard to have that change in. There is one significant advantage to this method, this
Re: [linux-dvb] Future of Multiproto
On Sun, Oct 07, 2007, Artem Makhutov wrote: I am wondering about the future of the Multiproto API. me too -- thanks for asking Will the Multiproto API be part of the upcoming DVB-API, is it just a short time solution to make the DVB-S2 devices work or is Multiproto the new DVB-API? For a long time I believed the API was basically agreed upon and Manu and IIRC Steve were implementing drivers. Once the drivers were ready (and thus proved the API works) the whole thing would've been merged. But I lost track of the DVB API update thread. Maybe Manu and Steve could fill us in what their conclusion of this thread was and what the plan is now. Thanks, Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Johannes Stezenbach wrote: On Sun, Oct 07, 2007, Artem Makhutov wrote: I am wondering about the future of the Multiproto API. me too -- thanks for asking Will the Multiproto API be part of the upcoming DVB-API, is it just a short time solution to make the DVB-S2 devices work or is Multiproto the new DVB-API? For a long time I believed the API was basically agreed upon and Manu and IIRC Steve were implementing drivers. Once the drivers were ready (and thus proved the API works) the whole thing would've been merged. But I lost track of the DVB API update thread. Maybe Manu and Steve could fill us in what their conclusion of this thread was and what the plan is now. Johannes / Manu, I'm actually pretty sad about the whole situation. The HVR4000 has been done for over a year, probably much more. Support for this product in the main v4l-dvb repository is stuck behind the multiproto tree, and that's going nowhere. People have been using the HVR4000 and multiproto patches with success, although more widespread thorough testing is always a good thing. Manu, I've pinged and pushed you on a number of occasions to publish an updated tree via hg on linuxtv and for various political reasons this has never happened. I think you made yourself pretty clear via private communications, and via the public DVB API thread.Without re-visiting (or-reigniting) those flames and bad feelings, I think it's clear to me that the future of multiproto being maintained and managed in the linuxtv/hg tree is not going to happen. I've offered to help by performing the merge, organizing testing and pushing the work to conclusion (final merge), but that doesn't appease you. I'm not writing this email from spite, I'm simply trying to help you, me and the rest of the community. But, either you have different plans for the patches or you'll give me the OK - here in this thread - to take your patches and begin working on them freely via linuxtv.org/hg Unless this happens, I repeat, I cannot see a future where the multiproto patches will be merged (after traditional peer review) into the main v4l-dvb repository. In which case, I believe, the patches are worthless. I really appreciate your efforts, but the patch is foundering and its been having a negative impact on the community for a very long time. All other suggested mechanisms for bringing multiproto into the kernel are unacceptable to me, and will only serve to highlight the obvious differences of opinion we have between various developers in the group. For that reason, unless the situation changes, I'm going to withdraw the HVR4000 tree pending a complete rewrite of the driver with no dependency on multiproto. If you point me at your latest code drop, I'll take it build a tree and begin driving the patch, saving you all the trouble. If you have other plans then I think you should state them here and now, for the record. Damn, I wish you'd just let me help and ignore the politics. - Steve ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Future of Multiproto
Steven, Steven Toth wrote: Johannes / Manu, I'm actually pretty sad about the whole situation. The HVR4000 has been done for over a year, probably much more. Support for this product in the main v4l-dvb repository is stuck behind the multiproto tree, and that's going nowhere. People have been using the HVR4000 and multiproto patches with success, although more widespread thorough testing is always a good thing. Manu, First of all, as a backgrounder, i am no more interested in the politics that which Johannes is fostering as of late. (Removed CC) That said, i do respect Johannes for what he had done in the past, but i am against his policies, ideas and concepts that he has been fostering and cherishing as of late. I will explain why, too. I've pinged and pushed you on a number of occasions to publish an updated tree via hg on linuxtv and for various political reasons this has never happened. I think you made yourself pretty clear via private communications, and via the public DVB API thread.Without re-visiting (or-reigniting) those flames and bad feelings, I think it's clear to me that the future of multiproto being maintained and managed in the linuxtv/hg tree is not going to happen. (Addressing your question on the DVB API thread) The DVB API thread is in the light that the broken things in the API should be fixed. (Some people like to state that those aren't broken) Well, i am not going to use the broken stuff and hence the thread. Now you might be interested to do that, because the cx24116 blindly does that, but as i can see the issues, i am not blindly following what someone states. (Addressing your comment on tree location) when you mean linuxtv/hg tree, there is just only one tree which is called thus http://linuxtv.org/hg/v4l-dvb/ Do you have write access to the repository ? Now, only one single person has access to this tree, so obviously you can't develop in that tree. What you mean to say linuxtv.org/hg, i believe you mean individual developer repositories such as ~stoth/ ~manu/ What difference does it make, if the tree is there elsewhere ? (what advantage does it get you other than you are allowed to have some space for storage at linuxtv.org) In fact having a tree elsewhere makes it easy for tree maintenance. Ok, that said you might suggest, still one should put all their code at linuxtv.org, for that community warmth. This can happen of course, but i have my requests also if that needs to be done, the current workflow needs to be changed. Please feel free to address that thread which exists on the v4l-dvb-maintainer ML, as it was discussed earlier as what is wrong with the workflow as it is, in case you would like to address them. (Basically i don't like those people who steal credits and or people wanking into code that which others do maintain and thus making it broken. Johannes earlier said slap such people, but these days he states that they do for your good. I don't see how that is good except that it brings me in larger headaches. True though it is good for person who is watching the spectacular events) Currently, there is no workflow defined. Right now the concept is, i take your code and i do whatever i want with it. I don't agree to that workflow. This is NOT the OSS philosophy I've offered to help by performing the merge, organizing testing and pushing the work to conclusion (final merge), but that doesn't appease you. I'm not writing this email from spite, I'm simply trying to help you, me and the rest of the community. But, either you have different plans for the patches or you'll give me the OK - here in this thread - to take your patches and begin working on them freely via linuxtv.org/hg (On your statement of a merge) A merge should happen when things are considered stable. At least as far as i can say, it needs some more efforts from my side. I am not for merging something that which needs more work and tests (Anyone who thinks different is in fact creating politics, why ? Generally we have the idea that release when done an not before is the general OSS philosophy. Now why is some people like Johannes creating a politics, whenever he get's the chance ?) First fix your code, then you merge, this is on a general note. if you see such merges/attitudes have only led to a rise of the largely broken code and or drivers. This attitude has to change, merge should happen on complete stuff. (On your statement, of me giving you Ok to do whatever you feel like) This is exactly what anyone would detest. This brings in just broken code/concepts only. Also this does mean that i have stopped working on it and thrown it away. Why is it that you think thus, i don't understand. Unless this happens, I repeat, I cannot see a future where the multiproto patches will be merged (after traditional peer review) into the main v4l-dvb repository. In which case, I believe, the patches are worthless. I really
[linux-dvb] Future of Multiproto
Hi, I am wondering about the future of the Multiproto API. Will the Multiproto API be part of the upcoming DVB-API, is it just a short time solution to make the DVB-S2 devices work or is Multiproto the new DVB-API? What about Multiproto support by other application? Is/will VDR, MythTV or any other DVB-Applications support Multiproto? How is the current status of it? Thanks, Artem -- Artem Makhutov Unterort Str. 36 D-65760 Eschborn ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
