Date: Sat, 5 Jun 1999 00:18:33 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: julian@whistle.com (Julian Elischer) Cc: nate@mt.sri.com, dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 Message-ID: <199906050518.AAA07966@dyson.iquest.net> In-Reply-To: <Pine.BSF.3.95.990604120347.16696A-100000@current1.whistle.com> from Julian Elischer at "Jun 4, 99 12:27:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > The problem was not that the original programmers were being ignored. > It's that the original programmers found it difficult to express to a > newcommer, the subtleties of what they had internalised years before. > > Both sides showed remarkable lack of patience.. Matt was in a hurry and > John was too busy to stop and really put his ideas down in simple terms. > Remember however that John had "retired" from FreeBSD, so there was no > original surity that he would give any help at all (though of course > those of us that know him knew he could always be asked for advise). > > I think the whole thing was a storm in a tea-cup and I thing that Matt > has been int he code now long enough that just the passing of time and > experience has made the decision as to whether he should get commit privs > back purely academic.. > I suggest that even the most expericenced and expert developer should adhere to reasonable development practices including the requirement for unit testing (individual tests on the developers own resources), and also system testing done by others. Some subsystems are more fragile and critical than others, but in order to minimize the mistakes in implementation, design review and input is also desirable. If a design discipline is adhered to, then many mistakes in implementation can be avoided. So, not only should there be a minimal testing process, a minimal (and non restraining) design process should be followed. This will minimize both algorithmic regression and stability regression. For major subsystems and a professional result in modification and design of existing subsystems, some form of discipline is needed (*none* of us is perfect.) The days of invent, hack, commit in important and existant subsystems is likely long gone. At one time that procedure was needed due to practicalities, but now there are emeritus and outside people interested in the success of the project, and many more resources are available upon request. (The invent, hack phases are still appropriate at times, but those who invent in a vacuum will continue to make the same mistakes that both original and outside developers had originally made. There is alot of info out there for the taking.) 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?199906050518.AAA07966>