Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.unix.questions Subject: Re: Trusting operating systems: vendor or university? Message-ID: <8013@brl-smoke.ARPA> Date: 4 Jun 88 21:46:20 GMT References: <1128@mcgill-vision.UUCP> <55239@sun.uucp> <1133@mcgill-vision.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 39 In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >They do? In my experience they generally ignore the bug reports. This is heavily vendor-dependent. For example, people at Gould would see a remark on the "gouldbugs" mailing list, draw up the SPR on my behalf, and send a timely response. That's hard to beat. >And my notion of fixing a bug involves getting >a fix to the person with the problem within a week. Not "in the next >major release - and oh yes, that will cost you $2500[1]". This is an entirely unrealistic notion. Even when I set up a corporate software support organization with adequate staffing, all that we promised was a RESPONSE to an official trouble report within one week. The response would not necessarily include a "fix" for the problem, although often we would promise fixes in the future and suggest interim workarounds. Quite often the trouble reporter had not found an actual software error, but rather had misinterpreted the specs, and the response would include an explanation to help the reporter understand. Our reporting mechanism was designed to elicit sufficient information for use to be able to reproduce the problem, but often we couldn't, so investigating it was hopeless and we would have to so respond. Other times the response was "We duplicated the problem but have not yet figured out what is responsible for it nor what to do about it. We will continue to investigate and may do something about it in the future." (Plus a suggested work-around, of course.) Responsible software organizations do NOT install "quick fixes" in existing systems (except in extreme emergencies), but rather analyze the problem, design an integrated solution, assign competent staff to implement the solution, merge it into the product, thoroughly test not only the problem area but also the rest of the product operation, update documentation as required, run the result through QA to the distribution department. Naturally this expensive process cannot be performed for every little bug, but is generally done on a regular basis for each product release cycle. Most major vendors I have dealt with have procedures similar to what I just described. Those few that have taken "quick fix" approaches I've generally found to cause more damage than they repair.