home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1262 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  5.2 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!sdd.hp.com!hamblin.math.byu.edu!yvax.byu.edu!heinrich
  2. From: heinrich@yvax.byu.edu (Ed Heinrich  - The LOKI Group, Inc.)
  3. Newsgroups: vmsnet.internals
  4. Subject: re: PATCH on ALPHA ?
  5. Message-ID: <1992Sep2.075848.905@yvax.byu.edu>
  6. Date: 2 Sep 92 14:58:48 GMT
  7. References: <00960015.DDB2E380.11192@WKUVX1.BITNET>
  8. Organization: Brigham Young University
  9. Lines: 93
  10.  
  11. In article <00960015.DDB2E380.11192@WKUVX1.BITNET>, Hunter Goatley <goathunter@WKUVX1.BITNET> writes:
  12. > <MILLER@TGV.COM> writes:
  13. >>
  14. >>
  15. >>We generally distribute patches as DCL files to avoid problems like that.
  16. >>On those occations when I need to read someone a patch over the phone
  17. >>I have them read it back to me before they perform an update.  Then I ask
  18. >>them to rerun patch and examine the new binary values before they run the
  19. >>new image.  With Patch we can have a fix out to the customer within an hour
  20. >>instead of the day or two it takes to ship a new tape.
  21. >>
  22. > Exactly.  When I used to work for Clyde Digital (now Raxco), PATCH and
  23. > I became very good friends.  Not that the code had so many major
  24. > problems, but rather that a lot of customers liked to have their own
  25. > [...]
  26. > ago, and is part of the reason I left there.)
  27. > 
  28. > By using PATCH to update an image:
  29. > 
  30. >   o  the customer had the fix or modification within minutes;
  31. >   o  as the developer, I didn't have to go back to the sources for
  32. >      the released product and make a change to them;
  33. >   o  I didn't have to release the current, not-even-in-alpha-test
  34. >      version of the product that already included the change;
  35. >   o  I didn't have to worry about having five or six different images
  36. >      that all did mostly the same thing.  The patches were easily
  37. >      categorized and customer support could dole out the appropriate
  38. >      patch to any customer who needed/wanted it.
  39. > 
  40. > By using REPLACE instead of DEPOSIT, we and the customer were assured
  41. > that they were patching the right place.  I don't remember ever having
  42. > a customer screw up a patch---even one that had been read to him over
  43. > the phone or FAXed to him.  Granted, that's pretty amazing, but.... 8-)
  44. > 
  45. >>Has any one else here had any problems using Patch?
  46. >>
  47.  
  48. I have to agree w/ both Bruce and Hunter.  For software companies that
  49. have large customer bases PATCH is invaluable.  The cost of creating
  50. new distribution tapes (including cost of a TK-50, operator time,
  51. overnight shipping, etc.) has been estimated by one comapny I worked
  52. for to be $45 per hour - the cost of distributing a patch command
  53. file is much lower.  In addition, many system managers WILL apply a
  54. patch if they are told it fixes a potential crash-related bug, they
  55. may not, however, rush to do a full installation if you send them a 
  56. patched distribution kit.  (I know of some shops that only schedule
  57. product upgrades during Christmas week when the plant is closed, but
  58. they will apply a PATCH when they receive it).
  59.  
  60. I think that the risk of a misapplied patch is LOW enough - assuming
  61. the author of the patch is competent, AND USES REPLACE - to justify it's use.
  62. In my experience bad patches have not been a problem, the only problems I 
  63. know of came as the result of a site having PATCH defined as a foreign 
  64. command to another utility and this was fixed by having our patch command 
  65. files always define PATCH to be the DEC image.
  66.  
  67. As Hunter points out, there are times PATCH can be used to tweak a
  68. product to a particular customer's requirements and that alone can
  69. make it useful.  Although I have gotten away from the pratice and now
  70. use a hidden qualifier, I used to have debugging code included in
  71. products that was turned off.  If a customer had problems that could
  72. not be reproduced in-house, I would give them a patch to enable that
  73. debugging code.
  74.  
  75. > 
  76. > I never had any problems using PATCH, but it doesn't surprise me that
  77. > a lot of people don't like it.
  78. >
  79. I think the real issue with PATCH is that a lot of people really don't
  80. understand it.  It is a very powerful tool if used properly.  To someone
  81. who is neither familiar with Macro-32 nor with the particular application,
  82. it may appear to be some sort of cryptic voodoo....  
  83.  
  84. The question of use vs. abuse of PATCH needs to be managed.  Companies
  85. need to insure that PATCHES are reflected in source code changes as
  86. soon as the patches are cut to avoid issuing subsequent releases with the
  87. same bugs.  (I used to work for a company that supported RSX-based 
  88. applications.  A friend of mine was transfered into a different group 
  89. and given the listings to read to learn the application.  After a day, 
  90. he went to the Project Leader and told him, "THIS CAN'T WORK.  THE SOURCE 
  91. CODE HAS TOO MANY BUGS TO EVER WORK".  The Project Leader said, "Oh yeah, 
  92. I forgot to give you all the ZAPs".  ZAP being the RSX equilivent of PATCH.)
  93.  
  94. For companies, such as TGV, that make the extra effort to resolve 
  95. problems at a customer's site ASAP, patch is an effective tool to have
  96. available and can make the difference between a one hour resolution
  97. time and a week's time.  
  98.  
  99. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  100. Ed Heinrich
  101. The LOKI Group, Inc.
  102. HEINRICH@yvax.byu.EDU
  103. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  104.