Date: Fri, 4 Jun 1999 00:56:25 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: brian@Awfulhak.org, dyson@iquest.net, ahasty@mindspring.com, crossd@cs.rpi.edu, freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 Message-ID: <199906040556.AAA05478@dyson.iquest.net> In-Reply-To: <199906040223.TAA01897@apollo.backplane.com> from Matthew Dillon at "Jun 3, 99 07:23:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > And this nonsense in another email about things being untested is also > complete bull. I had a machine dedicated to running test kernels 24 hours > a day. I still do. > Testing on local machines isn't generally sufficient, due to the need for running diverse applications in various environments that are often difficult to simulate. Local machine testing is only sufficient for testing very well understood changes or first level testing before the testing team can review and test the code. > > This is what I mean about rumors turning into supposed facts. The fact > of the matter is that what mistakes I made ( and I would argue that a > certain number of mistakes are unavoidable ) were all minor. > Sum of lots of minor mistakes and oversights (where the side effects are accumulated loss of features and/or optimizations without knowing it) end up being a significant regression in the form of loss of features, decrease in performance or changes in behavior that are difficult to track down. Alot of the code has complex interactions, and until the developer has a complete understanding of the various design choices and the interrelations between subsystems, it is extremely important to carefully regression test the changes. If mistakes are made because of information not being possible to retrieve or the mistakes are due to research and developing new technology, then they are understandable. If mistakes are made because of ignoring available information, and such information can provide enough insight to avoid the mistakes and/or regressions, then that should not ever be deemed to be acceptable. Even if a mistake is "excusable", it is still not desirable to *commit* such changes to a main branch until the new works are characterized and the effects are understood in a significant number of application mixes. Alot of work was previously done to characterize and model application mixes, and that is one reason why FreeBSD has performed so well in the past, and alot of performance regressions were avoided especially considering the amount of code and algorithmic design being newly developed. That sure isn't to say that regressions didn't happen, but the original developers of the code had very little support available in the form of experts in the field, assisting in avoiding the regressions. It was only in the 6mos or so before I left that a support team was slowly being put together by me. With about 1yr of commits ready to go, and being held off because of potential destabilization, I felt it necessary to pull together a group of people that would be willing to work on the code with me and help productize it before letting it loose on the community at large. The days of hack, patch, and commit were over a long time ago, and some kind of QC program was (and is still) needed. > > The biggest mistake that programmers working on a large project make is > when they do *not* rewrite portions of the code that need to be rewritten. > I suggest that is the 2nd biggest mistake. The first biggest mistake is that programmers working on a large project sometimes don't quite understand the code that they are working on, and rather than investing in understanding it so that if they choose to correct it or rewrite it, they rewrite it with a superficial understanding, and miss features that had previously existed. I have seen many times (not just on FreeBSD), that programmers will often avoid asking authors of code how it works, and rewrite it with the misconception that they understand it (even thinking that improvements are being made :-(). It is even worse to rewrite it in order to make it "readable", and as a side-effect loose features only to improve readability. Arguments that might claim that the readability is being improved so that future work will be made easier is only valid if the recoding doesn't break anything and the recoding shows that the original design of the code was understood well enough that significant enhancment has a high probability of being worthwhile and successful. Almost every programmer that I know has been guilty of this "sin", and probably happens most often when the programmer has more energy than patience. There is a need for alot of code cleanup in the system, but it is also important to do so in a way that loss of desirable behavior doesn't happen. Alot of the code was written to relentlessly deal with performance and behavior issues that aren't well understood by the community in general. In many cases there are design considerations that are almost insignificant when taken alone, but the cumulative improvement in behavior accrues rapidly. Many times an improvement in total performance is a result of improvement of apparently unrelated subsystems as an *intended* side-effect. When significant rewrites of sections of code are contemplated, I suggest avoiding a waste in time, and avoiding a wasteful and potentially devisive vested interest in a subproject that might end up creating an unintended regression in the system behavior. A good way to avoid the lossage would be to ask for conceptual reviews before coding is started. Such reviews can transpire either in informal email or by phone discussions. Even if the original changes could provide a net improvement in performance or behavior, there is a possibility that some additional improvements being a result of collaborative discussion. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906040556.AAA05478>