Re: Future of Multiproto

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
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.

Markus



_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux