>> 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
>> development kernels is that it's easier to keep track of what you're doing
>> if you do it all at once. Some people such as Alan Cox and Dave Miller
>> work on many different parts of the kernel. If they were politely informed
>> that a new feature they had added had broken something else shortly after
>> the release of the code then I'm sure that they would be able to either fix
>> the problem or give some background information that allows a less skilled
>> programmer to fix it with a minimum amount of effort. However if the bug
>> goes undiscovered for 6 months because no-one tries compiling a certain
>> combination of modules (or whatever the trigger is) then they are likely to
>> require much more work to fix it.
>By defining even more levels of "official" release policy, you are running
>the danger of blocking the creativity of the biggest contributers to
>Linux. In my mind, the model works like this:
I had no intention of implying that we should delay releases of kernels
for any reason. As I stated in the second paragraph that you quoted the
aim should be to discover bugs ASAP to enable them to be fixed more quickly
and easily.
Russell Coker