Re: Ingo, no more kconfig patches

[Thomas Gleixner]

On Sun, 4 May 2008, Adrian Bunk 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.

Interesting. You confidently define how kernel development works and
what affects it and what not. 

I just caught a build wreckage via randconfig builds on a patch which
was sent through Andrew to x86 for merging into mainline.

So you think that we should stop sharing with the wider kernel
community the fixes that result out of our automated randconfig builds
and should instead wait for Joe User or another kernel developer to
trip into some subtle missing Kconfig dependency, just because a fix
might not be the right one and might need another iteration before it
can go upstream?

You are wrong as usual.

I for one prefer getting a (even wrong) patch which points to the
problem instead of some (often grumpy) "this broke" message.

> Before you started your randconfig builds and sending (often buggy) 
> kconfig patches like crazy there wasn't a problem (and Toralf's 
> randconfig builds already catched these problems in the past).

FYI, Ingo has been doing randconfig build and boot tests for a long,
long time. There are dozens and dozens of (non-build) fixes in the
upstream kernel that resulted from that effort - it's really valuable
in practice.

So what you say is complete nonsense.

The RDC subarch commit was buggy, but that does not justify your
insulting and self-righteous behaviour at all. If you think that your
behaviour vs. Ingo is improving kernel development, then you are on
the completely wrong track. It might earn you an entry in his
killfile, but nothing else.

Thanks,

	tglx
--
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/