MIME-Version: 1.0
In-Reply-To: <20150522101219.GT21577@sirena.org.uk>
References: <CAD3Xx4KVq7PYWkRm4ZVWhZVscu5W3q1tW53EOu0Q9j7xp0iPzQ@mail.gmail.com>
 <20150522093534.GR21577@sirena.org.uk> <1432288344.27695.86.camel@x220> <20150522101219.GT21577@sirena.org.uk>
From: Valentin Rothberg <valentinrothberg@gmail.com>
Date: Fri, 22 May 2015 12:53:16 +0200
Message-ID: <CAD3Xx4LAO_O1CjoUz5XseRB=JHzyM16i7zLAqLEYgoi1a7_8bg@mail.gmail.com>
Subject: Re: regulator: da9062: undefined Kconfig option MFD_DA9062
To: Mark Brown <broonie@kernel.org>
Cc: Paul Bolle <pebolle@tiscali.nl>, stwiss.opensource@diasemi.com,
        lgirdwood@gmail.com, support.opensource@diasemi.com,
        linux-kernel@vger.kernel.org,
        Andreas Ruprecht <andreas.ruprecht@fau.de>,
        hengelein Stefan <stefan.hengelein@fau.de>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2469
Lines: 53

Hi Mark,

On Fri, May 22, 2015 at 12:12 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, May 22, 2015 at 11:52:24AM +0200, Paul Bolle wrote:
>> On Fri, 2015-05-22 at 10:35 +0100, Mark Brown wrote:
>
>> > > Is there a patch queued somewhere to add the missing Kconfig option?
>
>> > This is totally normal for merging MFDs where the MFD goes in via the
>> > MFD tree and the subsystem drivers go in via their trees.  This way
>> > subsystem maintainers don't have to sit through endless resends of the
>> > core driver.
>
>> So every time a driver is added to linux-next that depends on an unknown
>> symbol a boring message like this will be sent. And people can simply
>> respond to it with a link to the patch that adds the missing symbol.
>
>> It's a bit annoying. But it helps in catching errors as early as
>> possible. And it gives the people looking into these kconfig oddities
>> the info they need to keep track of things.
>
> For the common cases like new things being added over multiple trees I
> would expect people to be making some effort to filter these things
> before reporting manually - for example here a couple of moments of
> searching would have shown the rest of the series under review, or most
> likely waiting a few weeks before reporting would allow the MFD to get
> merged.

That was my initial approach, but it turned out that mailing lists are
not a good indicator if something is/will be/has been applied in the
big jungle of git trees.  In many cases, the missing option is part of
some series somewhere but, for various reasons, got lost on the way.
Catching those also entails the noise.

> One effect of being too keen to report things is that a high false
> positive rate will cause people to pay less attention, if the source is
> usually just generating noise then it gets tuned out.

Note, that we keep a list of all reported items.  If we know (for
certain) that something will be applied, we won't report anything
similar for a longer period of time.

I don't want those reports to be seen as spam, so I guess we need to
find a less noisy approach.  It's something I do as a hobby besides my
PhD, so the only intention is to help, not to annoy people.

Kind regards,
 Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/