[GIT PULL] omap changes for v2.6.39 merge window

[mingo@elte.hu (Ingo Molnar)]

* David Brown <davidb@codeaurora.org> wrote:

> When we push back, there is a good chance they just won't bother, not because 
> they don't want to do it, but because it doesn't fit a schedule, and there is 
> already something else for them to work on.
> 
> So what's the right answer here. [...]

IMO the right answer is what Linus and Thomas outlined:

   1) provide a small number of clean examples and clean abstractions
   2) to not pull new crap from that point on
   3) do this gradually but consistently

I.e. make all your requirements technical and actionable - avoid sweeping, 
impossible to meet requirements. Do not require people to clean up all of the 
existing mess straight away (they cannot realistically do it), do not summarily 
block the flow of patches, but be firm about drawing a line in the sand and be 
firm about not introducing new mess in a gradually growing list of well-chosen 
areas of focus.

Rinse, repeat.

If companies do not 'bother to push upstream', then management will eventually 
notice negative economic consequences:

 - Higher short-term production costs: upstream feedback/review/testing
   improves the product, so the lack of upstream feedback/review/testing
   increases the production costs of the product.

 - Higher long-term production costs: gradually slower SoC development due to a 
   morass of out-of-tree hacks that werent pushed upstream causing gradually 
   higher development costs. This means higher payroll costs and longer time to
   market - in which time more flexible competitors can beat you.

 - Brain drain: developers like to show their good work upstream as well, not
   just in some ship-and-forget out-of-tree kernel. Good developers will
   gravitate towards SoC companies that encourage them to work upstream.
   No matter how good of a business idea a company has if there's no good 
   developers.

 - Less revenue: a product can not possibly be more appealing to SoC customers
   if the upstream Linux kernel does not support it. As ARM moves up the food 
   chain towards more complex, higher profit margin products longer term 
   thinking gains foothold gradually.

 - Competitive disadvantages: most SoC competitors push their changes upstream,
   so they get free development assistance, they get free exposure, they get 
   free PR and they get opportunities. Not pushing upstream is a lost 
   opportunity.

All of these effects translate into real $$$$$$$ and affect the bottom line 
very directly, both short and long term. These costs also increase with time so 
they are not fixed.

If management does not actively encourage upstream-quality changes then 
management will have to justify why they exposed the company to these extra 
costs, complications and risks - just to save on the relatively minor (and 
fixed) cost of working with upstream.

If despite all that management still believes (rightly or wrongly) that it's 
cheaper for the company to do low quality throw-away code and does not care 
about any of the short and long-term costs listed above then this really means 
that they really do not care about you or about the upstream kernel - so they 
do not exist as far as the upstream kernel is concerned.

Why should you then reward them with pulling crap and why should you be willing 
to invest future maintenance overhead into their "we do not care about you" 
solution?

Working with upstream is a quid pro quo with plenty of advantages on both 
sides, which gives maintainers a heck of a leverage to push back on crap while 
still having all the incentives in the world to help produce a high quality 
kernel.

Thanks,

	Ingo