Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!rphroy!caen!sdd.hp.com!hp-pcd!hpfcso!mike From: mike@hpfcso.FC.HP.COM (Mike McNelly) Newsgroups: comp.sys.apollo Subject: Re: APRs (FLAME ON) Message-ID: <9330014@hpfcso.FC.HP.COM> Date: 15 Apr 91 16:26:01 GMT References: <9104082143.AA24021@pan.ssec.honeywell.com> Organization: Hewlett-Packard, Fort Collins, CO, USA Lines: 87 > mike@hpfcso.FC.HP.COM (Mike McNelly) writes: > > "Fixed in a future release" may seem like weasel-words but it's > > necessary if the name of a future release is not entirely stable. For > > example, consider the possible confusion to customers if the engineer > > had responded "fixed in release 11.xx" and that release was subsequently > > renumbered to 10.yy. > > > > Also, in the mad world of releases, sometimes unrelated releases > > unexpectedly leapfrog each other due to slips of one part or another. > > This accounts for some creative release renumbering and further > > confusion for everyone, the engineers included. > Naahhh, them's weasel-words alright! > If HP/Apollo really wanted to convey any concrete information in such a > report, they could either: > 1) Specify a _date_ by which the problem would be fixed. > 2) Specify a maximum number of releases that would follow before the > problem was fixed, i.e. "Fixed within two releases" or "Fixed in > the next release." > As a user, I would even be willing to be a _little_ generous when given > this kind of feedback, by allowing for a bit of slop in an estimate to > compensate for "leapfrog" releases and/or delays due to other significant > events (like acquisition by another company :-). > There's no disguising the fact that the only thing "Fixed in a future > release" says is "Don't call us, we'll call you." That's certainly not > what I want to hear from a technical support organization. > Of course, "Fixed in a future release" is infinitely better than "Performs > to specification," which (in some cases I have read about on > comp.sys.apollo) is the purest form of BS (bureaucrat-speak). > -- > Glenn P. Parker glenn@bitstream.com Bitstream, Inc. > uunet!huxley!glenn 215 First Street > BIX: parker Cambridge, MA 02142-1270 Again, I don't have anything to do with Apollo so my comments are based only on our own lab's procedures, not any other's. "Fixed in a future release" is used in only one context: The bug has been investigated, a fix has been implemented and installed, it's been tested, and we're waiting for a release train to hook the new code onto. This response is never used to describe anything that has not already been determined to be a problem and been fixed. We cannot specify a date for which a bug fix will be available because a) the bug has already been fixed as far as the lab is concerned. We're awaiting a way to get it out to the customers. b) We don't like to make statements that sound like promises we can't be sure we can keep. This is a matter of professionalism and integrity as much as anything else. c) We have a worldwide distribution for releases that can take a significant amount of time to crank up (e.g., released by xxx in the US doesn't necessarily satisfy anyone in Uganda. d) At the time the bug is fixed we frequently don't have a clear idea when the next release is to occur. Releases involve a large number of labs, marketing, support, manufacturing, etc. The humble engineer who fixes your problem may not be privy to the grand scheme (I really doubt that any grand pubah has a clue in the early stage, either). As to promising "within two releases", etc.: These responses don't entirely satisfy people, either and they're certainly pretty ambiguous. We make releases all the time for various hardware boxes, software packages, etc. that any single customer probably never knows about. It's a lot less clear what a release is now that we support such a large variety of machines and configurations. Occasionally we also run across problems that require coordinated action between two or more widely separated labs. I know customers don't care who fixes their problem but sometimes a fix in the debugger, for example, must also await a corresponding modification to the kernel. If the kernel isn't being turned for a particular release then the customer will not see the fix in the next release despite the best intentions of the debugger team. The whole point of these comments are to give you a little insight into what's involved in fixing problems and getting the fixes to you. If you've got suggestions I'd like to hear them, preferably off line. We can summarize later if that makes any sense. Keep in mind, though, that you're dealing with a humble engineer, not the master of the universe. Mike McNelly mike@fc.hp.com