Path: utzoo!attcan!uunet!lll-winken!elroy.jpl.nasa.gov!usc!snorkelwacker!bionet!agate!linus!philabs!ttidca!alter From: alter@ttidca.TTI.COM (Steve Alter) Newsgroups: alt.sources.d Subject: Re: Perl patches Message-ID: <19952@ttidca.TTI.COM> Date: 21 Sep 90 22:47:25 GMT References: <1990Sep15.193958.10955@iwarp.intel.com> <1990Sep16.170917.11901@lokkur.dexter.mi.us> <727@array.UUCP> <1990Sep21.020331.2225@zorch.SF-Bay.ORG> Organization: Citicorp/TTI, Santa Monica Lines: 73 In article <1990Sep21.020331.2225@zorch.SF-Bay.ORG> xanthian@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 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. } -- Steve Alter {csun,philabs,psivax,pyramid,quad1,rdlvax,retix}!ttidca!alter Citicorp/TTI, Santa Monica CA (213) 450-9111 x2541