`Brian Grunkemeyer wrote:> > > Why should you save 4 to six hours by costing linux additional time.> > One different configuration costs Linus extra time with no further> > guarantee that yours would work.  I think your recomendation is> > extremely extremely s e l f i s h !!> > Once again, if you actually read what I wrote instead of skimming it, you'll> see my suggestion would cost Linus 4-6 hours of time but little effot.  My> suggestion would save me and many other users & developers circa 20 minutes a> piece.  So if only 25 people end up saving 20 minutes, that's a net savings of> 25*.3 - 5 = ~3 hours of wasted time worldwide.  For other bugs that hit more> people, the time saved would be much much greater.  If you think trying to save> time and effort on a global basis is selfish, then we really won't be able to> agree on much.	We can't agree until you understand that what you stated is not assimple 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 theparticular bug that cost you time.     Supposing you provided the first two the probability that it addedsavings to you are others is n/1000000 where n is the number of configurationsthat 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 shouldreport 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 slipis noticed a notice is posted.  Most of your complaints are cleared if yousimply wait 2 days for the non-complainers to catch the bugs and take thetime to read them.     You like to assume i skimmed your words.  Not so.  They simply are notvalid.  Do the mathematics.  Determine the probabilities that 20 Additionalminutes of Linus' time would save anybody elses time.  My, analysis isthat 20 additional minutes (over what he already spends) would rarely catch any errors including typo's that you mention.  The probability is that they couldincrease the errors thereby costing more people time than you hoped to saveby introducing additional steps in the release proccess.  I am talking fromvast experience of trying to prevent errors.  There is a whole field ofresearch in this area and while true that the earlier errors are caught theless they cost to fix the jury is still out on whether you can prevent thmewith 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'tsee the flaw in the process until the quality control people find it.	My whole point is that the kernel list is where the product isprovided to the Quality control team.  If you do not want to be part ofthe test/Quality team wait until the test reports on in.  Most times thisleads to the releases of test fixes.  The new release so the cycle continues.	Nobody told you to assume that any of the releases were stableonly that It was hoped that it would prove stable.  Please test it andreport problems.  	This list is that back channel list between the Developer Linusand the other Developers and the Quality Control Team.  Don't complainabout it working.  Either wait for it to work or become part of it.	Linus is the developer not the QA.  It is well documented thatthese functions must be seperate.				Hubert`