We can't agree until you understand that what you stated is not as
simple as you think.
First who is to generate the automation?
Second who is to determine the proposed set of canadate configurations.
Third what is the probability that this sample set will catch the
particular bug that cost you time.
Supposing you provided the first two the probability that it added
savings to you are others is n/1000000 where n is the number of configurations
that were tried. You I and the others are providing the n configurations.
The fact that one problem can show up in n configurations is why we should
report the fact on the list ASAP.
Your basic assumption that Linus is careless in his releases is falicious!
He cares, and he apologizes if something slips. As soon as the slip
is noticed a notice is posted. Most of your complaints are cleared if you
simply wait 2 days for the non-complainers to catch the bugs and take the
time to read them.
You like to assume i skimmed your words. Not so. They simply are not
valid. Do the mathematics. Determine the probabilities that 20 Additional
minutes of Linus' time would save anybody elses time. My, analysis is
that 20 additional minutes (over what he already spends) would rarely catch any
errors including typo's that you mention. The probability is that they could
increase the errors thereby costing more people time than you hoped to save
by introducing additional steps in the release proccess. I am talking from
vast experience of trying to prevent errors. There is a whole field of
research in this area and while true that the earlier errors are caught the
less they cost to fix the jury is still out on whether you can prevent thme
with out a huge investment in Quality control at the front end that is
never performed by the developer.
The developer is usually totally blind to the problems. He doesn't
see the flaw in the process until the quality control people find it.
My whole point is that the kernel list is where the product is
provided to the Quality control team. If you do not want to be part of
the test/Quality team wait until the test reports on in. Most times this
leads to the releases of test fixes. The new release so the cycle continues.
Nobody told you to assume that any of the releases were stable
only that It was hoped that it would prove stable. Please test it and
This list is that back channel list between the Developer Linus
and the other Developers and the Quality Control Team. Don't complain
about it working. Either wait for it to work or become part of it.
Linus is the developer not the QA. It is well documented that
these functions must be seperate.