[linux-dvb] Future of Multiproto

Manu Abraham abraham.manu at gmail.com
Wed Oct 10 21:44:36 CEST 2007


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 exists per se. 
This confusion eventually results in ego problems and flames at large causing a standstill.


> Will your suggested improvements result in a single unified v4l/dvb tree
> under linuxtv.org, including the multiproto patches?


After reading the above mentioned steps, be your own judge, whether this question of 
yours will have any significance.

Manu



More information about the linux-dvb mailing list