burzio@mmlai.UUCP (Tony Burzio) (10/07/90)
Much has been said about the availability of HP patches from local SEs. The loal SEs from HP are an extremely valuable resource for our company. Many's the time that our program has been saved by help from our SE. However... The idea that "patches" are available only after you report a problem to the response center sounds like my car dealership. I always get a "Oh yeah, that's a warranty repair covered in a status bulletin, but you can't see them and we won't tell you until the wheels fall off". Pretty difficult way of getting information. How about this: HP mails out these neat 1 1/2" thick status bulletins every so often. What a waste of paper. How about a SHORT unbound list of available patches instead? This way, I could ask for a menu of tapes from my local SE, instead of bothering him all the time? Just a thought... Tony Burzio. mmlab!burzio@uunet
rer@hpfcdc.HP.COM (Rob Robason) (10/09/90)
tony> How about a SHORT unbound list of available patches instead?
I can see two sides to this:
1) I agree that it is a waste of time to have every customer
troubleshoot the same problem and isolate it to HP software. I too
think that it would be nice if there was a list of patches with
sufficient description to know if one applied to a current problem.
Note too that SEs are often as in-the-dark about existing patches as
you are. If you had access to such a list, would you be inclined to
install all or most of the patches? I think I would.
2) What happens if a customer chooses a standard procedure of
installing every patch that HP makes available? Patches are really
intended, and QA'ed, for installation on a "standard" released
system. There may be unexpected interaction between two or more
patches. We would like to limit patch distribution to those who
must have them to reduce the risk of introducing unexpected
interactions between these patches. The last thing we want to do is
have a critical problem introduced at a customer installation
because of a patch; for one thing it is immensely more difficult to
isolate on a non-standard (i.e. patched) system. I think this is
at least one reason for our reluctance to give these patches to
everyone.
The bottom line is that I think it would be useful to provide a list of
patches for customers to check, even if you still have to call the
response center to get one.
Caveat: My personal opinion is not a statement on behalf of HP, it's
just my personal opinion (and worth every penny you paid for it :-).
Rob Robasonbb@palmetto.cis.ufl.edu (Brian Bartholomew) (10/10/90)
In article <5570507@hpfcdc.HP.COM> rer@hpfcdc.HP.COM (Rob Robason) writes: >1) I agree that it is a waste of time to have every customer > troubleshoot the same problem and isolate it to HP software. I too > think that it would be nice if there was a list of patches with > sufficient description to know if one applied to a current problem. Agreed. > Note too that SEs are often as in-the-dark about existing patches as > you are. This is one of the main problems under discussion in this group. I am glad that someone from HP has finally admitted it. Perhaps now it can be corrected. > If you had access to such a list, would you be inclined to > install all or most of the patches? I think I would. Of course; I would install each and every problem fix I could get my hands on. I want the most correct and complete operating system I can get. That's what I am paying for. Would a car owner turn down a warranty repair on the brakes, for any reason? >2) What happens if a customer chooses a standard procedure of > installing every patch that HP makes available? Patches are really > intended, and QA'ed, for installation on a "standard" released > system. There may be unexpected interaction between two or more > patches. We would like to limit patch distribution to those who > must have them to reduce the risk of introducing unexpected > interactions between these patches. The last thing we want to do is > have a critical problem introduced at a customer installation > because of a patch; for one thing it is immensely more difficult to > isolate on a non-standard (i.e. patched) system. I think this is > at least one reason for our reluctance to give these patches to > everyone. This is the most damning admission I have heard on this group in several months. You have admitted that HP can not even keep their own bug fixes straight in their own house. Further, if HP is not confident enough in their own repairs to known they will work with their own software, then they aren't really repairs, now are they? Perhaps in the HP-UX technical support sales literature, HP should mention that the customer may have his choice of known bugs; but by company policy, in no case shall he be allowed to have a system completely free of bugs. Now that I read that again, perhaps it should be moved to the Sales Manual for the technical support managers... >Rob Robason "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu
milburn@me10.lbl.gov (John Milburn) (10/10/90)
In the referenced article bb@palmetto.cis.ufl.edu (Brian Bartholomew) writes: >In article <5570507@hpfcdc.HP.COM> rer@hpfcdc.HP.COM (Rob Robason) writes: >This is the most damning admission I have heard on this group in >several months. You have admitted that HP can not even keep their own >bug fixes straight in their own house. Further, if HP is not >confident enough in their own repairs to known they will work with >their own software, then they aren't really repairs, now are they? This is perhaps an overreaction. One of the things which sets HP appart from most other vendors is their extensive QA of released products. I believe the hesitation which Rob expressed comes from the fact that these patches have not been qualified through the complete test suite for an OS release. His point about possible interactions between patches is quite valid. It is certainly never intentional that patches would have some effect upon another part of the system, but in a system as complex as unix, you are never completely sure. I don't intend to appear as an apologist for hp (despite the quote in Unix Today :-} ), but I think the concerns expressed are valid, and that your response is somewhat over-critical. -jem -- JEMilburn@lbl.gov ...!ucbvax!lbl.gov!JEMilburn
jad@hpcndnm.cnd.hp.com (John Dilley) (10/10/90)
In article <24818@uflorida.cis.ufl.EDU> bb@palmetto.cis.ufl.edu (Brian Bartholomew) writes: >In article <5570507@hpfcdc.HP.COM> rer@hpfcdc.HP.COM (Rob Robason) writes: >>2) What happens if a customer chooses a standard procedure of >> installing every patch that HP makes available? Patches are really >> intended, and QA'ed, for installation on a "standard" released >> system. There may be unexpected interaction between two or more >> patches. We would like to limit patch distribution to those who >> must have them to reduce the risk of introducing unexpected >> interactions between these patches. The last thing we want to do is >> have a critical problem introduced at a customer installation >> because of a patch; for one thing it is immensely more difficult to >> isolate on a non-standard (i.e. patched) system. I think this is >> at least one reason for our reluctance to give these patches to >> everyone. >This is the most damning admission I have heard on this group in >several months. You have admitted that HP can not even keep their own >bug fixes straight in their own house. Further, if HP is not >confident enough in their own repairs to known they will work with >their own software, then they aren't really repairs, now are they? I think Rob's point is that our patches are QA'd on the previous release, not on top of the previous release with all available patches on it. To truly guarantee that a patch will not break a customer system, HP would have to test the patch on all of the following configurations: - the last "pure" QA'd release upon which the patch is supported; - the last release with all current patches applied; - the last release with every non-empty subset of patches applied. (Yes, I know, the second case is subsumed by the third :-). The combinatorics of this get very ugly (2^n) if many patches (n) go out. We keep the patches straight internally, but on limited configurations. >Perhaps in the HP-UX technical support sales literature, HP should >mention that the customer may have his choice of known bugs; but by >company policy, in no case shall he be allowed to have a system >completely free of bugs. Now that I read that again, perhaps it should >be moved to the Sales Manual for the technical support managers... HP does make every (reasonable) attempt to ship software free of bugs. When serious bugs do make it out in software (nobody is perfect) there is a need for a patch process to fix them. It's either that or hold up the release until all the bugs have been found and eliminated. In my understanding, though, only very serious bugs will get patches distributed. And patches go through our field force so the field can know what's going on, and can do their jobs supporting them. Given your above statement, however, I think you may fall into a set of customers whose needs HP may not understand well enough. Do you do your own support, or do you rely on HP support? In some environments having the "latest and greatest" is more important than having stable, known configurations (I used to be a university CS department admin, I understand the needs of that type of environment). For many of our major customers, however, a stable, known configuration is required. I don't think we can necessarily solve the needs of both environments with one solution. I also don't know if "unsupported patches" are something HP would consider ... but perhaps that's a potential solution? Personally speaking, I would love to see HP be one of the most responsive hardware and software suppliers while keeping up the level of HP quality. Keep the ideas coming ... someone is certainly listening... -- jad -- John Dilley Hewlett-Packard Colorado Networks Division UX-mail: jad@cnd.hp.com Phone: (303) 229-2787 -- This is not an official statement of Hewlett-Packard Corp, and does not necessarily reflect the views of HP. The information above is provided completely without warranty of any kind.
wayne@dsndata.uucp (Wayne Schlitt) (10/10/90)
In article <24818@uflorida.cis.ufl.EDU> bb@palmetto.cis.ufl.edu (Brian Bartholomew) writes: > > If you had access to such a list, would you be inclined to > > install all or most of the patches? I think I would. > > Of course; I would install each and every problem fix I could get my > hands on. I want the most correct and complete operating system I can > get. [ ... ] the most "correct and complete operating system" is the one that correctly runs your programs. if it aint broke, whatcha gonna fix? > > >2) What happens if a customer chooses a standard procedure of > > installing every patch that HP makes available? Patches are really > > intended, and QA'ed, for installation on a "standard" released > > system. [ .... ] > > This is the most damning admission I have heard on this group in > several months. You have admitted that HP can not even keep their own > bug fixes straight in their own house. Further, if HP is not > confident enough in their own repairs to known they will work with > their own software, then they aren't really repairs, now are they? > > Perhaps in the HP-UX technical support sales literature, HP should > mention that the customer may have his choice of known bugs; but by > company policy, in no case shall he be allowed to have a system > completely free of bugs. Now that I read that again, perhaps it > should be moved to the Sales Manual for the technical support > managers... uuuh, gee. have you ever tried to QA a large software system? do you know of any operating system that has _ZERO_ bugs? how can HP try to get bug fixes to critical problems out _quickly_ and still QA all the possible configurations? i used to be a sysadmin at a large IBM mainframe site. IBM has a very elaborate system to handle patches, tracking which patches you have installed, what optional products you have, which patches work with which other patches and which products, what versions of the operating system and products you were running, etc, etc, etc. it was all very nice and worked quite well as long as you kept up to date on the patches, applying only the ones that you needed in order to fix the problems you were having and had a good sysadmin to keep things running smoothly. we had one person who's major job duty was to apply patches. it took a fair while to learn how to use their patch system and IBM obviously put a lot of work into it. IBM also puts a lot of work into making things work right the first time, but asking for zero defects _and_ quick turnaround on new features, _and_ support of new hardware, _and_ backwards compatibility is asking for a lot. if _I_ had a complete list of patches available, i would apply _only_ the patches that would save me more time that it costs me to apply them. i have real work to do, and appling patches for things that dont effect me is just a waste of time. > [ ... ] That's what I am paying for. Would a car owner turn down a > warranty repair on the brakes, for any reason? sure, if i got a recall notice that my brakes on my car needed repair work, i would do it. but car companies never let you upgrade from your 1987 model to the current 1991 modem. car companies dont give you anywhere near as many options to a base model. sorry, in this one case i have to side with HP's. in my opinion, HP puts out some of the most solid hardware and software that i have ever seen. our unix box crashed yesterday, and i was shocked. it's the first time in over a year. i never had so few problems with any other system i have seen. not letting patches out to everyone probably helps a great deal. -wayne
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (10/11/90)
In article <24818@uflorida.cis.ufl.EDU> bb@palmetto.cis.ufl.edu (Brian Bartholomew) writes: ... > If you had access to such a list, would you be inclined to > install all or most of the patches? I think I would. Of course; I would install each and every problem fix I could get my hands on. I want the most correct and complete operating system I can get. That's what I am paying for. Would a car owner turn down a warranty repair on the brakes, for any reason? In many years of working on systems from Supercomputers to micros, I have NEVER known a vendor to provide perfectly safe "patches". This is true from IBM down to the fellow up the block. This is not like a product like an automobile. >2) What happens if a customer chooses a standard procedure of > installing every patch that HP makes available? Patches are really ... This is the most damning admission I have heard on this group in several months. You have admitted that HP can not even keep their own ... This is a statement of what everyone in the industry has always meant by a patch. There is a name for the complete set of patches to a product, AFTER complete QA. It is called a release. Patches are a way for a vendor to quickly respond to a users dire problem in a timely fashion. If you want complete QA, you can't have a timely fix. The risk of a minimally tested fix varies from site to site, from code to code and it is irresponsible for a system manager to indiscriminately load all patches on a system ... ANY vendors system. Perhaps in the HP-UX technical support sales literature, HP should mention that the customer may have his choice of known bugs; but by company policy, in no case shall he be allowed to have a system completely free of bugs. Now that I read that again, perhaps it should be moved to the Sales Manual for the technical support managers... Perhaps you have been working in a different industry than I ... I have never found a computer system to be bug free. Ever. The buglist for a mature IBM S/360 running a 15 year old OS at a very well manage site I used to consult to was a large phonebook sized document. Of course, lots of codes turn out to RELY on system bugs. Installing patches was a very careful and time consuming process .... as every patch was valdiated against ALL of the codes run at OUR site. This took weeks to months .... Needless to say, the system was "never up to date" in the sense you mean. It did, however, provide a stable development platform for upwards of a thousand programmers and support staffers. I am speaking for myself, not Sun, not HP or anyone else. "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!matrix.math.ufl.edu!bb University of Florida Internet: bb@matrix.math.ufl.edu -- ---------------------------------------------------------------- Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043