mouse@mcgill-vision.UUCP (der Mouse) (06/04/88)
In article <55239@sun.uucp>, limes@sun.uucp (Greg Limes) writes: > In article <1128@mcgill-vision.UUCP> der Mouse writes: >>... I trust one written by a company out to make money even less. > Funny, I would expect exactly the reverse. If the operating system > does not work properly, the company gets bug reports and has to fix > them They do? In my experience they generally ignore the bug reports. (My experience is limited to DEC and Sun, so this may not be a representative sample.) 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]". (Of course, I prefer getting source, so I can fix it myself that evening, instead of getting a black-box fix five days later. Source is another oven of flames I will refrain from opening just now.) Specifics of ignored reports? With DEC, I reported a bug in patch (VMS patch, even, not an Ultrix thing) via SPR. I never heard back, clear up to the time when we finally dumped VMS for good. (I also reported another bug, but that was my mistake, not a bug at all. They did get back to me on that one.) With Sun, I sent in one bug report and never heard a peep, though the bug went away with the next major version (or rather, was replaced by a different bug). I also sent in a dissection of some code printed in some Sun periodical publication (the STB maybe?) and was told, in effect, "we didn't say that code was worth diddly-squat; get lost"[2]. Those are the ones I recall; there may have been others. > Thus is it in the best interests of the for-profit corporation to > provide software that is as reliable and bug-free as possible. I agree. If only they would realize it. (Or perhaps I should say, if only they would pay attention to bugs that are bothering only a small proportion of their clientele.) der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu [1] Figure picked out of thin air. I suspect it's low. [2] Not in so many words. Details via email on request.
chris@mimsy.UUCP (06/05/88)
>In article <55239@sun.uucp> limes@sun.uucp (Greg Limes) writes [pro vendor]: >>If the operating system does not work properly, the company gets >>bug reports and has to fix them In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) answers [pro university]: >They do? In my experience they generally ignore the bug reports. ... >my notion of fixing a bug involves getting a fix to the person with >the problem within a week. (or at least a `hm, yes, that is a bug/ no, that is a feature | here is a workaround | we have no idea how to fix it yet but we are working on it', not dead silence: we can get dead silence from Berkeley for free :-) ) >Not "in the next major release - and oh yes, that will cost you $2500[1]". My own experience agrees with that of der Mouse, and applies to hardware vendors as well as software (viz. Emulex). Bug reports never get any answer, though the bugs do sometimes get fixed. Why should I pay for this `service' when UCB CSRG operates more or less the same way? And in their case the silence is excusable (CSRG can be described as `five guys weilding source code', and there is no one left to answer bug reports). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.UUCP (06/05/88)
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.
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (06/05/88)
In article <8013@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >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. A description of software maintenance in large responsible organizations deleted. I'm glad you wrote your response Doug, I was going to try to say it too but you're a better writer. The scenario you describe is exactly the one I work in every day. Maybe AT&T is doing something right on the product I work on? I can't speak for any others. Off on a tangent ... I think maintenance is going to be the Achilles heel of GNU. Its hard enough to do maintenance without worrying about what modified code is running on the machine. I guess we'll just have to wait and see if GNU can survive the test of time, (how tautological!). And please, no lectures on GNU please, I've heard enough. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (strange but true)
friedl@vsi.UUCP (Stephen J. Friedl) (06/06/88)
In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >They do? In my experience they generally ignore the bug reports. In article <8013@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > 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. I would have to assume that (in general) vendors would appreciate getting technical feedback on their products. Many of us exercise software in ways the vendor is not likely, and our reports and workarounds should help improve their products. What vendors perhaps don't realize is that we would like feedback on our feedback. Let's face it, if we find a clever bug, we would like to get some information on it: was it really a bug? Have they heard it before? Any word on a fix? Did they get it? I have sent in pages and pages of detailed bug reports to several vendors (especially Microport and TeleVideo) and heard next to nothing back from them. A one-way feedback path gets old very quickly. Vendors might want to take a long-term view of this and be a little more verbose in their feedback to their strongly technical users who take the time to provide good reports. -- Steve Friedl V-Systems, Inc. (714) 545-6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl Nancy Reagan on ptr args with a prototype in scope: "Just say NULL"
limes@ouroborous.wseng.sun.com (Greg Limes) (06/06/88)
BEFORE launching into this, I would like to reiterate the standard disclaimer: I do not speak for Sun. Please bear this in mind. I speak for myself, and sometimes I may see things as I would like them to be, instead of as they really are. So what is new? For those of you who just tuned in: In article <1128@mcgill-vision.UUCP> der Mouse writes: >I trust [an os] written by a company out to make money even less. In article <55239@sun.uucp> limes@sun.uucp (Thats Me!) writes: >If the operating system does not work properly, the company gets >bug reports and has to fix them In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) answers >They do? In my experience they generally ignore the bug reports. ... >my notion of fixing a bug involves getting a fix to the person with >the problem within a week. In article <11812@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >(or at least a `hm, yes, that is a bug/ no, that is a feature | here >is a workaround | we have no idea how to fix it yet but we are working >on it', not dead silence: we can get dead silence from Berkeley for >free :-) ) > >My own experience agrees with that of der Mouse, and applies to hardware >vendors as well as software (viz. Emulex). Bug reports never get any >answer, though the bugs do sometimes get fixed. Why should I pay for >this `service' when UCB CSRG operates more or less the same way? And in >their case the silence is excusable (CSRG can be described as `five guys >weilding source code', and there is no one left to answer bug reports). AND, in this article, I respond ... Folks, fixing bugs and getting the fixes out the door is not as trivial as some of you seem to think, and Sun is not as overstaffed as some others may think. My *entire* job consists of reading bug reports and trying to fix the problems described in them. I try to form an evaluation relatively quickly -- this is what Chris is asking about -- and it was my assumption that this evaluation was being forwarded to everyone who needed to know it, including the customer. As for sending a quick patch to the customer who called it in, see Doug Gwyn's article <8013@brl-smoke.ARPA>, and consider the meaning of the phrase "extreme emergency". -- Greg Limes [limes@sun.com]
rcsmith@anagld.UUCP (Ray Smith) (06/06/88)
In article <8013@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >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. > Gould also makes all of it's SPR's available to the public by dialup. They have put all of their SPR's in a HyperSearch infobase which is accessible by anyone with a modem. HyperSearch allows you to search the infobase by any word in the document. How's that for exposing yourself? For Doug, please send me some information on the "gouldbugs" mailing list? -- Ray Smith | USnail: Suite 200, 9891 Broken Land Pky, Columbia, MD 21046 Analytics, Inc. | GEnie : rcsmith (301) 381-4300 | CIS : 72000,1111 | Net : ...!uunet!mimsy!aplcen!anagld!rcsmith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The trouble with doing something right the first time is that nobody appreciates how difficult it was." -Walt West =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dan@maccs.UUCP (Dan Trottier) (06/07/88)
In article <11812@mimsy.UUCP> chris@mimsy.UUCP writes: >>In article <55239@sun.uucp> limes@sun.uucp (Greg Limes) writes >[pro vendor]: >>>If the operating system does not work properly, the company gets >>>bug reports and has to fix them > >In article <1133@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP >(der Mouse) answers [pro university]: >>They do? In my experience they generally ignore the bug reports. ... >>my notion of fixing a bug involves getting a fix to the person with >>the problem within a week. > >(or at least a `hm, yes, that is a bug/ no, that is a feature | here >is a workaround | we have no idea how to fix it yet but we are working >on it', not dead silence: we can get dead silence from Berkeley for >free :-) ) Well actually that's not quite fair. I remember bringing up 4.3 last May and not being able to get the networking going. I placed a call to Berkeley and got hold of Keith Bostic who went out of his way to find our problem. We arranged to work on the problem on a Saturday over the phone! By the end of the afternoon we had a work around and weeks later there was some bug fixes circulated (diffs on paper... patch can't read paper :-) that fixed the problem. This is from an organization that admits it won't provide support! > >>Not "in the next major release - and oh yes, that will cost you $2500[1]". It would be nice to see companies give free upgrades to people who report verifiable bugs. If a company was *really* interested in providing the best possible software I would think they would encourage users to find and report bugs! Some companies sucker buyers into debuging software for them and then turn around and sell the new and improved product. Of course those users that spend the time to report the bugs receive nothing in return. > >My own experience agrees with that of der Mouse, and applies to hardware >vendors as well as software (viz. Emulex). Bug reports never get any >answer, though the bugs do sometimes get fixed. Why should I pay for >this `service' when UCB CSRG operates more or less the same way? And in >their case the silence is excusable (CSRG can be described as `five guys >weilding source code', and there is no one left to answer bug reports). I agree, mostly. It seems that response time varies with the complexity of the bug. The real interesting bugs do seem to generate a response as do the trivial. There are however a class a bugs that are in between that pose problems not easily fixed and often require waiting for the next release of the software. The problem is getting past those people in charge of replying to bug reports and talking to those who fix the bugs. Now what about the bug in /usr/ucb/Mail that doesn't reconize "dan" and "dan@maccs" as being the same person! :-) -- A.I. - is a three toed sloth! | ...!uunet!mnetor!maccs!dan -- Official scrabble players dictionary -- | dan@mcmaster.BITNET
levy@ttrdc.UUCP (Daniel R. Levy) (06/08/88)
In article <8013@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: # 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. Would you care to give some case histories showing how you found this to be so? (You can leave out the names to protect the guilty.) This assertion would seem to imply a corollary that a raw bug fix is more likely than not to create another bug. My own experience with quick fixes (with internal CAD tools here at AT&T, developed and supported by Bell Labs) has been quite good. The tools are by no means bug-free, BUT I've rarely if ever seen a quick fix introduce another bug. -- |------------Dan Levy------------| THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY | AT&T Data Systems Group | Weinberg's Principle: An expert is a | Skokie, Illinois | person who avoids the small errors while |-----Path: att!ttbcad!levy-----| sweeping on to the grand fallacy.
ado@elsie.UUCP (Arthur David Olson) (06/08/88)
I'll put in a good word for Mt. Xinu here--an actual human being promptly acknowledges all of my bug reports, and the bugs get fixed in subsequent releases. Thanks gang! (Now if they had just forwarded the relevant ones to Berkeley. . .) -- Market swaps ends for Chinese native. (5) ado@ncifcrf.gov ADO is a trademark of Ampex.
rbj@icst-cmr.arpa (Root Boy Jim) (06/09/88)
From: Doug Gwyn <gwyn@brl-smoke.arpa> >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. Well, that is true, but only because the world we know is an imperfect one. Nevertheless, their is an `implied warranty of merchantibilty' on all goods sold. One could conceivably take a vendor to court because the system did not perform as stated in the documentation or specifications. The fact that this is not done is further evidence that the courts do not understand software, and that other solutions are livable. 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. Fair enuf where it applys. 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.) Also fair enuf. However, often the problem is known and/or a specific fix is suggested. Of course, this is only possible with source. 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. Again, in an ideal situation. But the bug *I* complain about is the most important one, and I should get it fixed for free, because that's the promise the vendor made (that it would work) when I bought it. If the vendor wants to ship me a whole new system to fix my one bug, hey, that's OK with me too, but I shouldn't have to pay for it. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/10/88)
In article <2737@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: ># Those few that have taken "quick fix" approaches I've generally found to ># cause more damage than they repair. >Would you care to give some case histories showing how you found this to >be so? I'll give just one example. Back when I was working for a small software firm whose products were totally dependent on DEC PDP-11 operating systems and compilers, we got monthly software update notes (bug fixes). It didn't take us long to discover that the way to use them was to wait at least two months to install suggested patches. The reason was that a disproportionately large percentage of the patches themselves were patched, usually in the next monthly update.
haugj@pigs.UUCP (John F. Haugh II) (06/11/88)
In article <2737@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > Would you care to give some case histories showing how you found this to > be so? Heck, I'll give you some case histories to show how it happens ;-) I worked for a company where I was very close to both the customers, as in customer support, and very close to the Big Bosses [ sorry, no more details, we get netnews at work ]. It was my job to get the customers off of the boss's back as fast as possible. Which frequently meant finding a very fast workaround which might have only had a life expectancy of three or four days. - John. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS "You are in a twisty little maze of UUCP connections, all alike" -- fortune