On Thu, 31 Mar 2011, Nicolas Pitre wrote: > On Thu, 31 Mar 2011, david@xxxxxxx wrote: > > > I think that part of the issue is that when Linus points out a problem, the > > response isn't "we agree and are working on it, here's what we are doing", > > instead it seems to be mostly "there is no problem, this is just because there > > is so much variation in ARM" > > If prominent people looking at this from the side line continue bashing > at those who are both feet in the mud trying to contain the flood rather > than actually helping then nothing will change. Instead this only > creates despair and the splashed people may simply decide to throw in > the towel, at which point things will collapse for real. In reality, > the system has been going as it is for quite a while and with more or > less the same level of intensity. And the fact is that _users_ of the > ARM kernel are not complaining. Things are far from being perfect, but > so far things have been "good enough" for the majority of the people > involved, and improvements are constantly being worked on with the men > power available. And that's the whole point why I was ranting in the first place. I know that there are clever folks working on the solution, but it's entirely clear to me, that they are simply not enough compared to the massive inbound flood. So neither you nor Russell can cope with it, you simply do not scale. That's why I suggested that the ARM community needs to push competent man power into this. You say the concept of subarch maintainers is working quite well. That depends on the definition of working. It works in terms of users can use it, but it does not work from a maintainability POV. Nobody wants to bash on those who are working on it, but IMNSHO the current way is running into an utter nightmare even w/o you and Russell throwing in the towel. I went through quite a few iterations of large scale cleanups, so I know how you feel. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html