🚀 go-pugleaf

In article <00960015.DDB2E380.11192@WKUVX1.BITNET>, Hunter Goatley <goathunter@WKUVX1.BITNET> writes:
> <MILLER@TGV.COM> writes:
>>
>>
>>We generally distribute patches as DCL files to avoid problems like that.
>>On those occations when I need to read someone a patch over the phone
>>I have them read it back to me before they perform an update.  Then I ask
>>them to rerun patch and examine the new binary values before they run the
>>new image.  With Patch we can have a fix out to the customer within an hour
>>instead of the day or two it takes to ship a new tape.
>>
> Exactly.  When I used to work for Clyde Digital (now Raxco), PATCH and
> I became very good friends.  Not that the code had so many major
> problems, but rather that a lot of customers liked to have their own
> [...]
> ago, and is part of the reason I left there.)
> 
> By using PATCH to update an image:
> 
>   o  the customer had the fix or modification within minutes;
>   o  as the developer, I didn't have to go back to the sources for
>      the released product and make a change to them;
>   o  I didn't have to release the current, not-even-in-alpha-test
>      version of the product that already included the change;
>   o  I didn't have to worry about having five or six different images
>      that all did mostly the same thing.  The patches were easily
>      categorized and customer support could dole out the appropriate
>      patch to any customer who needed/wanted it.
> 
> By using REPLACE instead of DEPOSIT, we and the customer were assured
> that they were patching the right place.  I don't remember ever having
> a customer screw up a patch---even one that had been read to him over
> the phone or FAXed to him.  Granted, that's pretty amazing, but.... 8-)
> 
>>Has any one else here had any problems using Patch?
>>

I have to agree w/ both Bruce and Hunter.  For software companies that
have large customer bases PATCH is invaluable.  The cost of creating
new distribution tapes (including cost of a TK-50, operator time,
overnight shipping, etc.) has been estimated by one comapny I worked
for to be $45 per hour - the cost of distributing a patch command
file is much lower.  In addition, many system managers WILL apply a
patch if they are told it fixes a potential crash-related bug, they
may not, however, rush to do a full installation if you send them a 
patched distribution kit.  (I know of some shops that only schedule
product upgrades during Christmas week when the plant is closed, but
they will apply a PATCH when they receive it).

I think that the risk of a misapplied patch is LOW enough - assuming
the author of the patch is competent, AND USES REPLACE - to justify it's use.
In my experience bad patches have not been a problem, the only problems I 
know of came as the result of a site having PATCH defined as a foreign 
command to another utility and this was fixed by having our patch command 
files always define PATCH to be the DEC image.

As Hunter points out, there are times PATCH can be used to tweak a
product to a particular customer's requirements and that alone can
make it useful.  Although I have gotten away from the pratice and now
use a hidden qualifier, I used to have debugging code included in
products that was turned off.  If a customer had problems that could
not be reproduced in-house, I would give them a patch to enable that
debugging code.

> 
> I never had any problems using PATCH, but it doesn't surprise me that
> a lot of people don't like it.
>
I think the real issue with PATCH is that a lot of people really don't
understand it.  It is a very powerful tool if used properly.  To someone
who is neither familiar with Macro-32 nor with the particular application,
it may appear to be some sort of cryptic voodoo....  

The question of use vs. abuse of PATCH needs to be managed.  Companies
need to insure that PATCHES are reflected in source code changes as
soon as the patches are cut to avoid issuing subsequent releases with the
same bugs.  (I used to work for a company that supported RSX-based 
applications.  A friend of mine was transfered into a different group 
and given the listings to read to learn the application.  After a day, 
he went to the Project Leader and told him, "THIS CAN'T WORK.  THE SOURCE 
CODE HAS TOO MANY BUGS TO EVER WORK".  The Project Leader said, "Oh yeah, 
I forgot to give you all the ZAPs".  ZAP being the RSX equilivent of PATCH.)

For companies, such as TGV, that make the extra effort to resolve 
problems at a customer's site ASAP, patch is an effective tool to have
available and can make the difference between a one hour resolution
time and a week's time.  
 
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Ed Heinrich
The LOKI Group, Inc.
HEINRICH@yvax.byu.EDU
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*