lkml.org 
[lkml]   [2008]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ingo, no more kconfig patches

* Adrian Bunk <bunk@kernel.org> wrote:

> > at minimum a warning needs to be emitted by the kconfig tool if such
> > incomplete selects are used. I've stopped counting the number of
> > times such issues have broken the build and have held up kernel
> > development.
>
> It might held up your randconfig compiles.
>
> Actual kernel development isn't much affected.

uhm, you are quite wrong - countless times have people been bitten by
select's breakages in the past, and not via randconfig. That's the main
reason why select use in Kconfig was not encouraged for a long time.

Select does make sense in some situations but it's a double-edged sword:
kconfig does not warn at all about the situations where it's "unsafe" to
use it - while it has all the information in the Kconfig files to emit
that warning. Instead we get build breakages not visible when an
incorrect select is added, but much later, if someone happens to stumble
on the wrong kind of .config. That is obviously harmful.

My larger point is that this kconfig tool bug breeds a constant stream
of avoidable breakages, which causes lost manpower and causes a stream
of trivial patches hindering maintainers all around the tree. Because
every such trivial patch has to be reviewed, tested, it clogs the commit
logs, etc.

So the more trivial patches we _avoid_ having to do in the future, the
better. I'm not sure why you are even arguing against this this rather
simple point - your arguments are rather hard to understand. Wouldnt you
be happier if a whole category of trivial breakages was avoided and if
you didnt have to deal with and waste your time on that category of
trivial patches anymore?

Most of the time reoccuring trivial patches are an indicator of some
deeper structural problem - as in this case.

Ingo


\
 
 \ /
  Last update: 2008-05-03 23:55    [W:0.074 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site