Steven Toth wrote: > hermann pitton wrote: > >> Am Mittwoch, den 10.10.2007, 23:44 +0400 schrieb Manu Abraham: >> >> >>> 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 >>> >>> >> Something always tells me, let it. >> But to do so also would not be fair to those trying in the future. >> >> Example. >> >> There is no saa7134 maintainer currently. >> >> What ever happened to the first? >> >> You are not innocent! >> >> But for sure Andrew tried always the best and had most of the workload. >> Holger got imposed the kernel i2c and was not happy, but that was not >> invented by Gerd. >> >> Example 2, dvb-pll. >> >> Dvb-pll came into kernel 2.6.12 and Gerd forced it over Andrew (M) and >> then did quit. After having for ever endless patches to maintain for >> every new kernel, because NACKed on everything hybrid for much too long. >> >> You still provide the story that he simply liked to have family and kids >> this time, easily possible within the already high amount of work within >> the _usual_ conditions. But not within this never ending/nacking DVB >> heroes stuff! >> >> Derived from Example 2. >> >> Johannes and Holger announced that they would allow dvb-pll for >> inclusion, if Gerd would do this on a cvs account provided for him and >> maintain it for his lifetime. >> >> Note for derived example 2. >> >> Mauro tries to fix some totally unimportant spelling issue on it, >> and you and Mike behave like dogs with a bone in question. >> >> I have _nothing_ to add here. >> >> Example 3. >> >> You claimed to have all NDAs/docs to provide support for recent >> NXP/Philips stuff and since then our second saa7134 maintainer was not >> seen anymore. He did a lot! >> >> You should do it then, please start. >> >> To make one thing clear. >> >> On Steve we have seen how one can provide support, there is nothing to >> discuss. >> >> >> >> > Providing support, yes that's basically my point. > > In response to the defined workflow, I don't think having active > maintainers for every piece of code is viable and sustainable. I think > Manu wants something which cannot be done, and I suspect that's part of > a bigger agenda. I'm not trying to annoy people, I'm trying to move the > group forward and get new features into the API meaning broader O/S > adoption. Isn't that why we're all here? > > Speaking purely for myself, my involvement with linuxtv varies depending > on my other work commitments. For this reason, I do not expect to review > every patch which gets created against the various drivers I've ever > brought to life. So, Manu's idea doesn't work for me, and I have no idea > whether it would work for Mauro (higher up my foodchain). > > I think collectively, this group has to decide whether we want to pursue > Manu's multiproto patches given his unwillingness to release them in the > current climate, or think again with an alternative solution. > > It's a great waste of effort to have to rethink S2 support just because > we have some differences of opinion within the group. But ultimately, if > we can't come to an agreement then the patches are worthless and we have > to find another way to move forward, either short term tactically or a > longer strategic view.... Neither of these sound appealing. > > One final thought. You would not believe how many individuals and > commercial companies have contacted me re: HVR4000 S2 support in Linux. > It's an important _missing_ feature. > > - Steve > > Hi, After a disappointing multiproto debate on IRC today I've decided to remove the ~stoth/multiproto and ~stoth/HVR4000 trees from linuxtv.org. I no longer support the multiproto patches and I'm seeking alternative ways to deliver the HVR4000 S2 driver to the community. For the time being I am no longer taking emails for HVR4000 related issues, please do not contact me directly about any HVR4000 related source code. All HVR4000 source code I've previously released is licensed under GPL and that does not change, you are welcome to use it within the terms of the license. A new driver will be published in the near future. Regards, Steve _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
