[linux-dvb] Future of Multiproto
stoth at hauppauge.com
Wed Oct 10 17:30:41 CEST 2007
Markus Rechberger wrote:
> Manu Abraham wrote:
>> 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.
>> 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
>> 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
>> 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.
> 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.
More information about the linux-dvb