Re: [PATCH] power: make goldfish option have a dependency on goldfish

[Anton Vorontsov]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/