On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux <li...@arm.linux.org.uk> wrote:
> If companies are going to go off and invent the square wheel, and that > makes *them* suffer the loss of being able to merge back into the > mainline kernel, thereby making *their* job of moving forward with > their kernel versions much harder, then yes, we *are* happy. russell: they have more employees than sense :) they also don't have any idea of what they *should* be doing, so this is an opportunity to educate them. they're not feeling any pain: they just employ more chinese developers and substitute bodies for time and common-sense. also, in this particular case, thanks to their script.fex system when i said they only need to develop one kernel and one u-boot i really wasn't kidding around: they really have got to the point which everyone else dreams of with device-tree [admittedly by limiting the product range that their clients can play with, but that product range has huge returns, so they're still happy]. > Companies will always do idiotic things; it's *them* and their users > who have to live with the results of that bad decision making process. russell: the decision process they've made is actually an extremely effective one. > Eventually, the pain of being outside the mainline kernel will become > too great, especially if their users demand things like kernel upgrades > from them. Eventually, they will change. > > And no, this isn't an intransigent position. This is reality given > that ARM already has way too much code in the Linux kernel and we're > trying to reduce that through the use of technologies like DT. The > last thing we need right now is for another "DT" like implementation > to come along which is only used on a minority of platforms - even if > the platform it is used on is successful. > > The way this works is this: > - you either go with the policies which are set, or .... which they weren't consulted on, it has to be pointed out. > - you change the policy as a whole because you have a technically > superior solution i believe they have a technically more *successful* solution. whether it's more appropriate in a wider context is another matter. here we have a key to the crux of the problem: the linux kernel maintainers have to cater for _everyone_. with no funding or incentive from the major contributors to work with them. hmmm.... > What that means in this case is either you adopt DT, or you convince > everyone that DT isn't the solution, but your solution is, and we adopt > your solution for *everything* instead. > > If neither of those are possible, then that's really not our problem, > and it's not _us_ who are being "intransigent". indeed. ok. so. we come back to the question again: what shall i propose to them that they consider doing, and what benefit would it be to them to do so? i cannot go to them and say "you have to do this [insert proposal here]" - it has to be more subtle than that. l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPweEDyYt+pN+UaFuqWL5RrHpyuq_4So-tArmx3dr=0wls+...@mail.gmail.com
