Hi Joachim,
there are two of your commits [1, 2] in today's linux-next (i.e.,
next-20150506). Both of them add Kconfig options that depend on
ARCH_LPC18XX, which is not defined in Kconfig, see:
+ depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
Is there a patch queued somewhere to add ARCH_LPC18XX ?
I detected this issue with ./scripts/checkkconfigsymbols.py by diffing
yesterday's and todays' linux-next trees.
Kind regards,
Valentin
[1] 13a43fd9e905 ("gpio: add lpc18xx gpio driver")
[2] 3aba09daf3d4 ("pinctrl: add lpc18xx pinctrl driver")
On 6 May 2015 at 10:02, Valentin Rothberg <[email protected]> wrote:
> Hi Joachim,
>
> there are two of your commits [1, 2] in today's linux-next (i.e.,
> next-20150506). Both of them add Kconfig options that depend on
> ARCH_LPC18XX, which is not defined in Kconfig, see:
>
> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>
> Is there a patch queued somewhere to add ARCH_LPC18XX ?
Currently it's only on the mail list.
See: http://marc.info/?l=linux-arm-kernel&m=143016894704253&w=2
Some drivers are going upstream before the base support.
regards,
Joachim Eastwood
> I detected this issue with ./scripts/checkkconfigsymbols.py by diffing
> yesterday's and todays' linux-next trees.
>
> Kind regards,
> Valentin
>
> [1] 13a43fd9e905 ("gpio: add lpc18xx gpio driver")
> [2] 3aba09daf3d4 ("pinctrl: add lpc18xx pinctrl driver")
On Wed, May 6, 2015 at 10:02 AM, Valentin Rothberg
<[email protected]> wrote:
> Hi Joachim,
>
> there are two of your commits [1, 2] in today's linux-next (i.e.,
> next-20150506). Both of them add Kconfig options that depend on
> ARCH_LPC18XX, which is not defined in Kconfig, see:
>
> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>
> Is there a patch queued somewhere to add ARCH_LPC18XX ?
Yes, and in this case it solves more problems to merge these
patches out-of-order than not to.
Yours,
Linus Walleij
Hi Linus,
On Tue, May 12, 2015 at 12:40 PM, Linus Walleij
<[email protected]> wrote:
> On Wed, May 6, 2015 at 10:02 AM, Valentin Rothberg
> <[email protected]> wrote:
>
>> Hi Joachim,
>>
>> there are two of your commits [1, 2] in today's linux-next (i.e.,
>> next-20150506). Both of them add Kconfig options that depend on
>> ARCH_LPC18XX, which is not defined in Kconfig, see:
>>
>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>>
>> Is there a patch queued somewhere to add ARCH_LPC18XX ?
>
> Yes, and in this case it solves more problems to merge these
> patches out-of-order than not to.
Could you explain those problems? I have some research interest in
such cases and want to understand and identify reasons for such
things.
Kind regards,
Valentin
> Yours,
> Linus Walleij
On Tue, May 12, 2015 at 12:48 PM, Valentin Rothberg
<[email protected]> wrote:
> On Tue, May 12, 2015 at 12:40 PM, Linus Walleij
> <[email protected]> wrote:
>> On Wed, May 6, 2015 at 10:02 AM, Valentin Rothberg
>> <[email protected]> wrote:
>>
>>> Hi Joachim,
>>>
>>> there are two of your commits [1, 2] in today's linux-next (i.e.,
>>> next-20150506). Both of them add Kconfig options that depend on
>>> ARCH_LPC18XX, which is not defined in Kconfig, see:
>>>
>>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
>>>
>>> Is there a patch queued somewhere to add ARCH_LPC18XX ?
>>
>> Yes, and in this case it solves more problems to merge these
>> patches out-of-order than not to.
>
> Could you explain those problems? I have some research interest in
> such cases and want to understand and identify reasons for such
> things.
What we want as maintainers is to keep GIT trees in isolation
without too much cross-dependencies. Often done by assuming
optimistically that patches are orthogonal.
Non-trivial dependencies are for example if one patch introduce
a header file that another patch is using, the result will
not compile, so we need to resolve to the exit strategies of:
- (A) Applying the same patch to two trees, which will be
handled by git as the patches are textually identical.
- (B) Creating an immutable branch pulled into both trees, which
is better since it means the same hash is in both trees
- (C) apply to one tree, wait for the merge window, and postpone
to the next kernel cycle, which delays development
Whenever we can orthogonalize patches it makes our job
easier.
Kconfig symbols added in one tree and used in another
does not create compilation wreckage and will resolve nicely
in linux-next and during the merge window, however the
trees still have a formal dependency which would argue that
you should go back to option (B) above in the ideal case
and create an immutable branch.
However doing that for something that you, as a human
maintainer, know will fix itself later, is surplus process for
the sake of process and "never making mistakes" which
cost more than it yields in maintainer time, thus making it
a time-cost economically rational decision not to go to all
the trouble of setting up an immutable branch but instead
rely on some uncertainty and laziness to save time.
The answer to whether a certain maintainer will dare to do so
or not is per individual preference. The crucial point is that
"time savings" trumps "nothing can ever go wrong".
Yours,
Linus Walleij
On Tue, May 12, 2015 at 2:03 PM, Linus Walleij <[email protected]> wrote:
> - (B) Creating an immutable branch pulled into both trees, which
> is better since it means the same hash is in both trees
PS: This may seem idea but it's not. It means several
subsystem-disparate patches will appear in several pull requests
and you have to explain why it's so to Linus (the big penguin,
not me). So again, orthogonal trees are preferred, if
possible.
Yours,
Linus Walleij
Hi Linus,
thanks a lot for taking your time to give such detailed answer, I
appreciate that.
On Tue, May 12, 2015 at 02:03:33PM +0200, Linus Walleij wrote:
> On Tue, May 12, 2015 at 12:48 PM, Valentin Rothberg
> <[email protected]> wrote:
> > On Tue, May 12, 2015 at 12:40 PM, Linus Walleij
> > <[email protected]> wrote:
> >> On Wed, May 6, 2015 at 10:02 AM, Valentin Rothberg
> >> <[email protected]> wrote:
> >>
> >>> Hi Joachim,
> >>>
> >>> there are two of your commits [1, 2] in today's linux-next (i.e.,
> >>> next-20150506). Both of them add Kconfig options that depend on
> >>> ARCH_LPC18XX, which is not defined in Kconfig, see:
> >>>
> >>> + depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
> >>>
> >>> Is there a patch queued somewhere to add ARCH_LPC18XX ?
> >>
> >> Yes, and in this case it solves more problems to merge these
> >> patches out-of-order than not to.
> >
> > Could you explain those problems? I have some research interest in
> > such cases and want to understand and identify reasons for such
> > things.
>
> What we want as maintainers is to keep GIT trees in isolation
> without too much cross-dependencies. Often done by assuming
> optimistically that patches are orthogonal.
>
> Non-trivial dependencies are for example if one patch introduce
> a header file that another patch is using, the result will
> not compile, so we need to resolve to the exit strategies of:
>
> - (A) Applying the same patch to two trees, which will be
> handled by git as the patches are textually identical.
> - (B) Creating an immutable branch pulled into both trees, which
> is better since it means the same hash is in both trees
> - (C) apply to one tree, wait for the merge window, and postpone
> to the next kernel cycle, which delays development
>
> Whenever we can orthogonalize patches it makes our job
> easier.
>
> Kconfig symbols added in one tree and used in another
> does not create compilation wreckage and will resolve nicely
> in linux-next and during the merge window, however the
> trees still have a formal dependency which would argue that
> you should go back to option (B) above in the ideal case
> and create an immutable branch.
>
> However doing that for something that you, as a human
> maintainer, know will fix itself later, is surplus process for
> the sake of process and "never making mistakes" which
> cost more than it yields in maintainer time, thus making it
> a time-cost economically rational decision not to go to all
> the trouble of setting up an immutable branch but instead
> rely on some uncertainty and laziness to save time.
>
> The answer to whether a certain maintainer will dare to do so
> or not is per individual preference. The crucial point is that
> "time savings" trumps "nothing can ever go wrong".
I understand your point completely. However, I see some cases critical,
especially when configuration conditional code is added that cannot be
compiled since the Kconfig option is not added yet or due to some other
reason. In precise, I see a conflict in the golden rule of "don't break
the build". As the code cannot be compiled, nobody knows if it's broken
or not. I see such things happening nearly daily.
But I am no maintainer, so I am not experienced in the daily challenges
of managing so many trees and understand the desire to save time.
Thanks again!
Kind regards,
Valentin
> Yours,
> Linus Walleij
On Tue, May 12, 2015 at 4:57 PM, Valentin Rothberg
<[email protected]> wrote:
> [Me]:
>> The answer to whether a certain maintainer will dare to do so
>> or not is per individual preference. The crucial point is that
>> "time savings" trumps "nothing can ever go wrong".
>
> I understand your point completely. However, I see some cases critical,
> especially when configuration conditional code is added that cannot be
> compiled since the Kconfig option is not added yet or due to some other
> reason. In precise, I see a conflict in the golden rule of "don't break
> the build". As the code cannot be compiled, nobody knows if it's broken
> or not. I see such things happening nearly daily.
I would say it is based on individual trust. Some contributors do not
send me untested patch sets so I know I can apply one or two of them
in isolation and trust the end result to be good if they work like this.
Individual trust is at odds with process. Process is based on the
bureaucratic ambition to work predictably and impersonal, such as
works the planets, or the plants. But maintainers in practice, while
applying some process, eventually work by personal trust which
is more ephemeral.
Yours,
Linus Walleij