On Wed, Jun 02, 2010 at 11:43:06PM -0700, Brian Swetland wrote: > > I guess it becomes an question of economics for you then. Does the cost of > > whatever user-space changes are required exceed the value of using an upstream > > kernel? Both the cost and the value would be very hard to estimate in > > advance. I don't envy you the decision... > > Well, at this point we've invested more engineering hours in the > various rewrites of this (single) patchset and discussion around it > than we have spent on rebasing our trees on roughly every other > mainline release since 2.6.16 or so, across five years of Android > development. We think there's some good value to be had (all the > usual reasons) by heading upstream, so we're still discussing these > patches and exploring alternatives, but yes, from one way of looking > at it, it'd certainly be cheaper to just keep maintaining our own > trees. And let's be blunt. If in the future the Android team (which I'm not a member of) decides that they have invested more engineering time than they can justify from a business perspective, the next time someone starts whining on a blog, or on Slashdot, or at a conference, about how "OMG! Google is forking the kernel!!!", or "Google is making the lives of device driver writers for the embedded world difficult", it will now be possible from a political point of view to point and the hundreds, if not thousands, of e-mail messages of LKML developers wanting to redesign this effort and saying "Nyet! Nyet! Nyet!" to the original patchset, to point out that Google has a made an effort, and gone far beyond what is required by the GPL. Not only has the source code been made available, but hundreds of engineering hours have been made trying to accomodate the demands of LKML --- and LKML has said no to suspend blockers/wakelocks. Realistically, a company makes decisions about whether to pursue engineering efforts based on business plans, and this is true whether the company is Red Hat, or Novell, or IBM, or Google. One of the cost/benefits can be things that aren't easily measured such as public relations. But past a certain point, it may be that the right answer is to make a single public appeal to Linus, and if he says no, or if he ignores the pull request, then the company at hand can say, "We've done the best that we could, but the Linux developer community, and Linus specifically, has refused our patch". And yes, it's all about PR, but let's not kid ourselves --- the GPL and bad PR can't be used as blackmail to force a company to invest arbitrarily unlimited amounts of engineering effort just to satisfy the mandarins of the LKML and/or Linus. And if people want to call this a fork, Linus has in the past said that sometimes forks are healthy, and necessary, and we can see how things play out in the marketplace. Disclosure: I work at Google, but I'm not at all involved in the Android development team, and it's not at all my call when Brian and his team should make a decision that they've invested more time/energy than can be justified to their management --- heck, they even roll up to an completely different VP than I do. :-) - Ted -- 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
