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 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 ? >> >> >> > I don't want to comment too much here, although this is the one and only > serious problem this project has which I'm concerned about. > And since fixing problems _together_ after pointing to them doesn't work > out this is the reason why alternative ways have been developed. > I don't expect that someone will write patches keep them in a repository > point out to those patches will run after several people for ages to get > those issues fixed. > Many things turned out to be private issues between developers making > the contributions of several other developers more difficult to get in. > My personal opinion about this is it's not acceptable. If whoever wants to > contribute his contribution or consideration should be taken seriously. > Agreed. > This is no one man or a few people know it all project - the result can be > seen on linuxtv.org and the rest of how far the project could be > could be seen if all external projects would be pulled together. > > Your comments I think are subjective and a matter of opinion. I may of actually miss-interpreted them. You're always free to express your opinions. Either way, I have nothing negative or positive to say regarding this statement. - Steve _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
