* Adrian Bunk <bunk@kernel.org> wrote: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 --
| Greg Kroah-Hartman | [PATCH 006/196] Chinese: add translation of oops-tracing.txt |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Borislav Petkov | 2.6.23-rc1: no setup signature found... |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [BUG] New Kernel Bugs |
