>> Linux kernel typos generally cost me about
>> 20 minutes to find a fix then the time it takes to do a partial
>> kernel compile. I admit, its a lot less, but its still a cost.
>> This cost is incurred by anyone compiling that kernel under a bad
>> configuration, assuming they try to fix it. Otherwise they just
>> lose the time they spent patching and partially compiling the kernel.
>
> If you don't want to see small problems in your kernel then don't
> upgrade until the rate of new kernel appearance has slowed to a crawl.
> You seem to want to be on the bleeding edge and to not have problems as
> well. If it is frustrating then find a kernel that works for you, take
> a breather, enjoy using it for a time and come back to a newer one later.
The bleeding edge? 2.0.xx was supposed to be stable; 1.3.xx and 2.1.xx
are the bleeding edge. Nobody is complaining that bleeding edge kernels
are unstable or won't compile. I don't even mind that Linus sometimes
releases a bleeding edge kernel without compiling it at all. If 2.0.xx
is bleeding edge, then let's just stop this code freeze nonsense and
announce the fact on comp.os.linux.announce.
Maybe the numbering scheme should be modified a bit. Maybe Linus
should ask Digital for a whole cluster of Alphas so that he really
can compile every option automatically. The 2.0.xxB suggestion
was good I think. We are lucky RedHat hasn't tried to ship one of
the recent broken kernels.
I still get a warning about a mismatched type when I compile hosts.c
in the SCSI code. Yes, I _did_ try to fix it myself but I got lost
inside some huge macro. (with aha152x, though others with different
cards report the same)