I think this would be very difficult. I don't believe any of the
"core" kernel hackers have access to all the hardware that Linux
supports, and hence they can't ensure that nothing gets broken. As
has been pointed out, it's better that things are left in a
non-compiling state than being subtly broken. Hopefully the active
maintainers of various sections of the kernel have a private mailing
list where Linus/David/Alan etc. could post messages saying "By the
way, I'm starting to re-write <foo>; if this will affect anything you
maintain, this may well break your code."
because of this, however if a serious testing effort was applied to the
pre-patches it would provide a list of things that need work. Then
hopefully most of these issues would be fixed before the full releae of the
2.1.x version.
>b) You cannot verify everything, and I bet just because ISDN compiles for
>you, doesn't mean that the SCSI driver for my Amiga compiles for me.
I believe that I have proved that it is impossible to test all
combinations of kernel options. But I believe that if we test a reasonable
number of kernels then we can discover (and therefore fix) bugs that might
otherwise hang around for ages. One reason for doing this in the
Perhaps people should be encouraged to download the {pre-,}patches and
build a kernel for their own configuration. They wouldn't necessarily
use the kernel once they'd compiled it, but would report back if the
compilation failed. One problem is that the kernel now takes up such
a large amount of disk space, some people may not be able to spare the
space (2.1.35, the most recent tree I have on my machine, takes 31Mb
and that's just the source (no object files around)).
[snip]
-- Martin Radford | martin@zamenhof.demon.co.uk | M.P.Radford@exeter.ac.uk"Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" - Linus Torvalds