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?