Trusting operating systems: vendor or university?

[gwyn at brl-smoke.UUCP]

In article <1133 at mcgill-vision.UUCP> mouse at 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.