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 appreciate your efforts, but the patch is foundering > and its been having a negative impact on the community for a very long > time. Now, this is the kind of thing that brings in politics. If you don't allow me to do whatever i like with your code, stating in a different light that there is no future for it, or that it cannot be merged. Generally, these kind of ideas come from Johannes, if you have talked to him, he will inject with all those things till one goes his way. To be very frank, i am really sick of his ways, from many thread and many discussions. (He just wants to have his stuff done irrespective of what others feel. Well, this is not the OSS/GPL philosophy) > 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. Why talk about highlighting the problems, but rather why not try to fix the problems ? Currently as it stands, my position is that unless there is a workflow position redefined, i am just at the same position that which i am at. As i wrote above, the current workflow is all for broken drivers and code with oopsy daisies around. It is only for preaching for some not practising, the practising is for others. The current workflow is unacceptable to me, the same way that you have stated "unacceptable to me". Maybe you are happy with broken drivers, i am not. > 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. HVR4000 is your tree and i don't force you, what you want to do with your tree. But that said, if you think that there should be 2 different API's, you are in fact being forced to join the politics that which has been created by somebody else. By doing so, you will be essentially splitting up the community, while on one hand talking about the community. (Talk a lot about it, while doing exactly the opposite) That said, i am having again more DVB-S2 demods at hand. By contributing more to this political thread, i take a backstep in terms of development of good working drivers and infrastructure. To put it short, waste of time. > 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. It would be, if some others stopped creating them. Although as it states "beauty is in the eye of the beholder", might be more appropriate. By writing such mails, (See who initiated the politics to be created, even in this thread) you are just a pawn in that politics, even without your knowledge, you are contributing to the same. As a sidenote: i will state what the problem is in this community at this time in one sentence Mauro likes certain things to be done "the way he likes", he licks Johannes back side for that, Johannes says yes, yes .. mauro says yes, yes.. Both moan together. 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. Ok now to give you an idea, just check who was against the merge of the same and who is asking for a merge, as though a flick of a switch, a person who said the code was crap. (Find the facts for yourself). Now what caused that flick of the switch (politics ?) Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
