Perl patches

[Steve Alter]

In article <1990Sep21.020331.2225 at zorch.SF-Bay.ORG> xanthian at zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
} I've seen a couple of newbie responses saying "no, perl wasn't released
} with that many patches"; these are folks looking at modern perl, not the
} initial release.
} 
} As for why it was such a particular irritation to me, my host site was
} a school system, perennially short for space, so I'd download perl to
} my home system (tedious in the extreme on a slow modem), delete it from
} the host site, and Boom! -- another patch.  Since no "patch" was available
} for my home system in those days, _upload_ perl, _patch_ perl, _download_
} perl, _delete_ perl on the host, iterate 25 more times.

Answer: port "patch" to your system.  It's becomming a de-facto standard
part of UNIX anyway and some vendors (e.g. Solbourne) are including it
as a real standard.

} Folks releasing things in dribbles don't realize the byzantine transport
} mechanisms and tool compromises some of their audience has to suffer
} to accomodate their habit, nor just how much inconvenience they cause by
} posting the source and the patch rather than the patched source.  It looks
} like a couple minutes work to fix if you work in a monocomputer environment,
} but it may make several hours' work for some of your recipients.

Many packages such as perl are very large, which renders complete
re-posting after every patch totally out of the question (it would jam
up network bandwidth and system disk space and force many sites to
impose severe expiration times or even disconnect.  Besides, some
people *want* to know, in line-by-line detail, what has changed between
version x and version x+1 and diff-listings (such as those used as
input to patch) are perfectly readable.  With small to medium packages,
complete re-posting after every <n> patches (choose a reasonable value
for n) may be feasible, but not really so for the biggies, unless you
make n very large, such that the re-posting interval is measured in
years instead of weeks.

The *only* other alternative (and one that I'd like to see implemented)
is to gather up more bug-fixes and feature-enhancements at a time
before sending out a new patch.  Might even want to send out bug-fixes
in a separate patch (or set of patches) from the feature-enchancements
so that some of us paranoid users can install the bug-fixes and wait
on installing the feature-enchancements until the next set of bug-fixes
comes out (there will always be more bug-fixes.)

For me it's a hassle to patch, make, and install the same program more
often than, say, every 3 months, because I've got to justify the new
version to my manager and to the users at my site, and I've got to go
through this procedure of installing the new version using a temporary
name, letting new co-exist with old for a time, then deleting the old
and renaming the new to the normal name.

} As a
} general rule, do as much work as possible where it can be done once,
} rather than send out the work undone to have its manhour consumption
} multiplied thousandfolds.

Note those keywords in there: "... as possible where it can be done
once".  You should also add the word "feasible" to the word "possible".
If you require developers to go an unreasonable extra mile to satisfy a
wider audience then they will, in many cases, just say:

	"Oh, screw it!  You want it perfect, you write it yourself!"

and what might have been a significant contribution to the network
(which Perl is, no doubt) would never appear.  We gotta accept what
they give.

} Kent, the man from xanth.
} <xanthian at Zorch.SF-Bay.ORG> <xanthian at well.sf.ca.us>

-- 
Steve Alter        <alter at ttidca.tti.com>
{csun,philabs,psivax,pyramid,quad1,rdlvax,retix}!ttidca!alter
Citicorp/TTI, Santa Monica CA  (213) 450-9111 x2541