Rafael J. Wysocki wrote:My point was about "obvious" errors, and I really think that one or two configuration will found most of these, doing in an automatic way, and without delay the process. Anyway more test are surely better. BTW, IIRC there are already few "testing farms" which tests automatically a lot of environment and configuration (IIRC, also run time tests). few hours, but a lot of changeset will broke bisect (few doc tell us how to continue bisecting on compile errors). But I agree with you. As usual, "One level more indirections" ;-) . Along a spamfilter, we (or Linus) need a patch filter. ciao cate PS: I don't want to be pessimistic. I only want to raise the problem, to see if it is possible to improve testing environment without affecting the development of Linux. --
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Alex Chiang | [PATCH 1/4] Remove path attribute from sgi_hotplug |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Eric Dumazet | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
