merlyn@iwarp.intel.com (Randal Schwartz) (09/16/90)
In article <1990Sep15.104022.22648@zorch.SF-Bay.ORG>, xanthian@zorch (Kent Paul Dolan) writes: | There is sufficient precedent, John. Or have you forgotten the initial | release of Perl, followed instantly by 26-some patches? | | It was along about patch 20 that I realized I would never, for love or | money, write a line of Perl code, I was that angry at Larry's release | methods. Larry released a major revision of a language that runs on nearly every machine known to man that smells a bit like UNIX. He could not possibly test this language on every system that ran it, so he made his best guesses. Some of it didn't work. The early patches fixed those. Then, people ask him for "feature X", which he adds, willingly. (Try *that* with your favorite vendor.) Then someone says "feature X doesn't work under Ultrix 3.2". So he fixes it, in record time (try *that* with your favorite vendor!). Bingo, another patch. Someone else says "here's how to make it work under MS-DOS". Bingo, another patch. There have really only been about five major subreleases in the *year* that Perl 3.0 has been out on the market. It's at patchlevel 28 because of the maximum size of a patch (one of the releases consisted of around 15 patches!). So *don't* write in Perl because of your personal prejudice against an effective method of handling problems and requests. Your loss. Not mine. I'm quite content with having the power of Perl (even a constantly improving one) at my fingertips for a little bit of effort once a month or so. Just another Perl hacker, -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/
scs@lokkur.dexter.mi.us (Steve Simmons) (09/17/90)
xanthian@zorch (Kent Paul Dolan) writes: > There is sufficient precedent, John. Or have you forgotten the initial > release of Perl, followed instantly by 26-some patches? > > It was along about patch 20 that I realized I would never, for love or > money, write a line of Perl code, I was that angry at Larry's release > methods. merlyn@iwarp.intel.com (Randal Schwartz) writes: > [[defends Larry, saying his 28 patches were done in a much > small number of batches]] Without meaning to take sides, I think Randal has missed something. When the initial c.s.u release of perl came out, it was released *with* 26 or so patches. Not already at patchlevel 26. The s.c.u release was the shar files for patchlevel zero plus 26 patches. I too was upset by this, and dropped a note to Rich and Larry. To my knowledge this has not happened again. As for releasing many patches in batches, I kind of like it. If you can get things down to one feature per patch (I know, Larry doesn't do that) it makes it easier to track which patch caused/cured a given problem. A release management issue, really. Kent Paul Dolan also writes: > It was along about patch 20 that I realized I would never, for love or > money, write a line of Perl code, I was that angry at Larry's release > methods. Your choice, Kent. Respectfully, it's your loss. You should reconsider. I didn't use perl until I hit a situation that couldn't be done reasonably in awk/sed/etc. It turned out to be easier than I expected. As I told the boss, tho, "it's heavily commented because it's write-only code."
rob@array.UUCP (Rob Marchand) (09/18/90)
In article <1990Sep16.170917.11901@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >xanthian@zorch (Kent Paul Dolan) writes: >> There is sufficient precedent, John. Or have you forgotten the initial >> release of Perl, followed instantly by 26-some patches? >> [some of Kent's stuff removed] > >merlyn@iwarp.intel.com (Randal Schwartz) writes: >> [[defends Larry, saying his 28 patches were done in a much >> small number of batches]] > >Without meaning to take sides, I think Randal has missed something. When >the initial c.s.u release of perl came out, it was released *with* 26 or >so patches. Not already at patchlevel 26. The s.c.u release was the shar >files for patchlevel zero plus 26 patches. > Leave us not forget, Perl has evolved a *great* deal, in _response_ to user requests and input. The initial release of Perl was (IMHO) remarkably useful, and quite reliable. Many of the patches released for Perl have added or improved functionality, while correcting outstanding problems. This has contributed to the number of patches. >I too was upset by this, and dropped a note to Rich and Larry. To my >knowledge this has not happened again. > >As for releasing many patches in batches, I kind of like it. If you can >get things down to one feature per patch (I know, Larry doesn't do that) >it makes it easier to track which patch caused/cured a given problem. A >release management issue, really. > The one fix per patch concept would be nice in terms of managing the problems. However, for small patches, it might become more bother than it is worth. I like to take the patch, fire it through patch in the right directory, and allow the source to be updated. Then I can redo a Configure, and/or make, or whatever, minimizing the time that I have to take to update something. I find Larry's (and other authors as well) software easy to maintain precisely for these reasons. >Kent Paul Dolan also writes: >> It was along about patch 20 that I realized I would never, for love or >> money, write a line of Perl code, I was that angry at Larry's release >> methods. [Steve's comments about Perl deleted] As Steve notes, Perl is rather useful; I've found it handy, and use it fairly extensively. Also, don't forget folks, most people on the net have *job* requirements to fulfil; they aren't necessarily being paid to perform acceptance testing on the software they release to the public. By releasing it to the ever hungry net community, obscure problems in implementation and portability are quickly brought to light. -- Rob Marchand UUCP : uunet!attcan!lsuc!array!rob Array Systems Computing ARPA : rob%array.UUCP@uunet.UU.NET 200-5000 Dufferin Street Phone : +1(416)736-0900 Fax: (416)736-4715 Downsview, Ont CANADA M3H 5T5 Telex : 063666 (CNCP EOS TOR) .TO 21:ARY001
tneff@bfmny0.BFM.COM (Tom Neff) (09/21/90)
In article <1990Sep21.020331.2225@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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. > >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, All this means is that if you want to be part of an ongoing development project like Perl, don't do it on a tinkertoy setup where patching is a terribly laborious process. If you must use such a setup, wait a few patches before rebuilding, or ignore the whole thing until a stable version is released. There are plenty of people whose systems accomodate new patches in a matter of minutes. Leave the intensive development cycle to them. Mere "patch envy" is a user problem. -- Nobody wants justice. /\ \/ Tom Neff -- Alan Dershowitz /\ \/ tneff@bfmny0.BFM.COM
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/21/90)
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. 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. 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. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peltz@cerl.uiuc.edu (Steve Peltz) (09/21/90)
In article <1990Sep21.020331.2225@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >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. You're telling us that you could bring up perl on your home system, but not patch? Now that is truly amazing. -- Steve Peltz Internet: peltz@cerl.uiuc.edu PLATO/NovaNET: peltz/s/cerl
alter@ttidca.TTI.COM (Steve Alter) (09/22/90)
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 <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@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- Steve Alter <alter@ttidca.tti.com> {csun,philabs,psivax,pyramid,quad1,rdlvax,retix}!ttidca!alter Citicorp/TTI, Santa Monica CA (213) 450-9111 x2541
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/23/90)
peltz@cerl.uiuc.edu (Steve Peltz) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> 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. >You're telling us that you could bring up perl on your home system, but not >patch? Now that is truly amazing. If you check, you'll notice the words "_compile_ perl" occur nowhere in the quote. This was long before a compiler existed for my system robust enough to handle that much source code, but archiving it away for later days was possible. I think the point is still being missed here. Larry Wall had, when he release perl, about 26 patches _in_hand_, but rather than make the first release at patch level 26, released patchlevel 0 and 26 patch postings. Good sense would suggest limiting the work of patching _when_ _the_ _patch_ _is_ _in_ _hand_ to the site of origin, rather than multiplying the work by distributing unpatched code. This is not a call to stop using patch, not a call to stop distributing beta code, not a call to stop distributing patches, just a call to use some sense when doing software releases. Why the arguments? Does someone think it made more sense the way Larry did it? If so, why? It caused more work, used more bandwidth, and came to the same product at the end. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jgreely@morganucodon.cis.ohio-state.edu (J Greely) (09/23/90)
In article <1990Sep23.004118.2745@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >I think the point is still being missed here. Larry Wall had, when he >release perl, about 26 patches _in_hand_, but rather than make the first >release at patch level 26, released patchlevel 0 and 26 patch postings. Wait a minute. As long as I've been paying attention, he's been posting source to a moderated source group and patches to comp.sources.bugs. If this is what happened with the initial Perl release, how long did the sources sit in the queue? Long enough for the really interested folks to ftp it and suggest changes and patches? We all know how willing Larry is to improve his software in response to user requests (which is either a virtue or a fatal personality flaw, depending on which side you're on). Regardless, this whole discussion is has nothing to do with Perl as it exists now, so I don't see why it continues (well, actually, I *do* understand, but I'm in too nice of a mood to bring it up). -- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
meissner@osf.org (Michael Meissner) (09/27/90)
In article <1990Sep23.004118.2745@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: | I think the point is still being missed here. Larry Wall had, when he | release perl, about 26 patches _in_hand_, but rather than make the first | release at patch level 26, released patchlevel 0 and 26 patch postings. Good | sense would suggest limiting the work of patching _when_ _the_ _patch_ _is_ | _in_ _hand_ to the site of origin, rather than multiplying the work by | distributing unpatched code. This is not a call to stop using patch, not a | call to stop distributing beta code, not a call to stop distributing | patches, just a call to use some sense when doing software releases. Why the | arguments? Does someone think it made more sense the way Larry did it? If | so, why? It caused more work, used more bandwidth, and came to the same | product at the end. My dim memory is that Larry sent the version 1 of perl off to comp.sources.unix, and it sat there for a bit. He also made it available for anonymous FTP. By the time the time c.s.u was ready to post it, there were 26 patches. I sometimes think that folks don't realize how diverse the UNIX systems are out there (and that Larry's code tends to poke in a lot of dark corners). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?