* David Brown <davidb@xxxxxxxxxxxxxx> 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 -- 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
