On Wed, May 23, 2012 at 02:21:50PM +0800, Andy Green wrote: > >>If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not > >>having Androidization patched in, people will stop wanting to get rid > >>of the patches. But since Google's interest is in the case it is > >>configured, I doubt they took care about having it disabled well. > > > >For new or optional functionality, this is usually the case, but not > >for all changes. Having multiple config based code paths has > >additional maintainance burden, so frequently if a change really > >should be generic there isn't any need for a config. The simplest > >example of this are bug fixes, which shouldn't be configurable off :) > > For an example we had a problem yesterday with the Androidization > "interactive" cpufreq governor turning up unexpectedly in an Ubuntu > build and spamming block task logs. I dunno why it appeared yet, > maybe it's marked up as defauly=y or some config fumble on part of > guy who built the kernel.
Generally when analyzing a situation like this I think the first question is whether feature X will be merged upstream, and then the question is whether it would be protected by CONFIG_ANDROID. How does the interactive governor fair against this criteria? Will it be accepted upstream, and if so, will it be behind CONFIG_ANDROID=y? > >>Initially we added without discrimination that 7 year old patch that > >>turns dmesg into junk to llct because it came in with Google's > >>Androidization series. It suggests we're just shovelling them on > >>without any plan at the moment. > > >And I'd say in this case things worked ideally! Android tree had a very > >old hack that has since become obsolete. You noticed it in the tree and > > Yeah but that's what I am saying, we shovelled the patches on with > no plan about assessment or audit and just waited for trouble. It's > fair enough to do that on android-specific tree because it's for > benefit of Android guys. But some vanilla people don't want to > participate in finding bugs from non-mainline Android code they > don't care about. Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable? (If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.) > Personally I like the idea of the Androidization becoming part of > the basis because it puts us in generally converged direction with > mainline. But then we have a responsibility to make it as > transparent as mainline will insist that it is if we expect members > are seriously going to offer vanilla kernels on this basis. I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
