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
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
