Re: [PATCH] power: make goldfish option have a dependency on goldfish
From: Paul Gortmaker
Date: Wed Feb 27 2013 - 21:17:42 EST
On Wed, Feb 27, 2013 at 8:35 PM, Anton Vorontsov <anton@xxxxxxxxxx> wrote:
> 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.
As you should, and nobody will fault you for that objective.
> 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
So, you actually want my change then -- you do not want to test for
goldfish power issues unless goldfish is selected. This is how I see
> 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;
I can not see how the above is at all relevant. If someone sends you a
patch for ARCH != x86, then your workflow will fail, regardless of what
actually is within the patch. As a maintainer, you need to be able to
handle cross compiles -- you can't escape the slightly more detailed
testing requirements we need to get from subsystem maintainers. There
are cross compile capable toolchains on kernel.org, and I use them
regularly before sending out changes that can impact multiple arch.
We can forgive individual contributors for not being arch aware, but
at the subsystem maintainer level, folks should be arch aware, and
doing regular x-compiles.
> 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
I am confused here. If there are correct depends lines here in the Kconfig,
then it _protects_ you from suffering like this. Yet, you want me to think
that it adds new work, new cross compile requirements and so on. I do
not see how that can possibly happen.
> 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? :)
No, I do not agree. In fact I see it as totally the opposite. But I already
said that I would not pursue this further, based only on differing points
of view, and so, after sending this, I will adhere to that now.
> 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
I think what I sent matches the above criteria. If you still are convinced
that I am incorrect in this regard, then I hope you can point to explicit
specifics that can convince me I am wrong. At the moment I do not
see anything to convince me that is the case. We are expanding work
for maintainers, testers, and people doing build coverage for no return
whatsoever, including yourself.
> 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/
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/