On Wed, Feb 27, 2013 at 07:48:38PM -0500, Paul Gortmaker wrote: [...] > If you don't want to take the commit, I won't argue it any further, but > I genuinely do hope the above logical arguments perhaps might cause > you to change your mind.
As a maintainer of drivers/power/, I have to keep things in a sane state, which means, that I want to compile-test the patches that I am merging. Testing patches takes time, and if I have to do it for all bunch of different machines and architectures, it becomes mess and unmanageable. In another words, it is easier for me to use as little different setups/.configs/cross-compilers/trees/etc as possible. For example, here is the scenario: - someone sends me a patch for goldfish driver; - I quickly compile it on my [underpowered] x86 laptop without need for cross-compilation and special configs; - It compiles fine, produces no warnings, so I happily send out the 'Applied, thanks!' email; Now, with your patch: - Someone sends me a patch for goldfish driver; - I starting to look for my cross-compilers collections, making all the environment setups, setting up a new build tree, looking for the outdated goldfish config, the ARM thing fails to build somewhere in arch/arm/plat-foo and drivers/mfd/bar. I become grumpy... and, you might not believe me, I open and edit drivers/power/Kconfig and remove needless 'depends on' (that is, I actually do these kind of things when I feel lazy enough). Do you agree that without the additional deps life is easier for me? :) If so, please do help me and the rest of the maintainers: instead of adding the unneeded deps, for consistency just remove those which are not needed. Thanks, Anton p.s. Quick answers for the rest of your arguments: > The linux-next compile queue as it is today barely gets completed within > a 24h window. So, it is large enough already, and nothing we can do about it, things are growing. But the good news is that no human attention is needed to compile things. That is what machines are for. :) > --why shouldn't we restrict the maintenance overhead of CONFIG_FOO > to people who really do care about supporting and testing and updating > features conditional on CONFIG_FOO? Given the size of the kernel > today, this seems to make sense in terms of developer "load balancing". You don't have to enable/fix everything. Some things become broken, so just disable them for the time being. But when people stumble upon broken drivers, the drivers are either get fixed, or removed (if no one wants to fix it). Sweeping drivers under 'depends on' doesn't do anything good in this regard, IMO. If we notice that goldfish is broken for long time and nobody cares to fix it, then it is a good time to think about its removal. Since goldfish has nothing goldfish-specific, it can be broeken only in a generic way, so if it is broken on x86, it is as well broken for ARM. > If you don't want to take the commit, I won't argue it any further I don't want to take it for a reason, but I do care whether my reasons make sense to you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
