Path: utzoo!dciem!array!rob
From: rob@array.UUCP (Rob Marchand)
Newsgroups: alt.sources.d
Subject: Re: Perl patches (was Re: shar 3.49 (part 2 of 2))
Message-ID: <727@array.UUCP>
Date: 18 Sep 90 12:59:51 GMT
References: <541@cpsolv.CPS.COM> <542@cpsolv.CPS.COM> <18546@rpp386.cactus.org> <1990Sep15.104022.22648@zorch.SF-Bay.ORG> <1990Sep15.193958.10955@iwarp.intel.com> <1990Sep16.170917.11901@lokkur.dexter.mi.us>
Organization: Array Systems Computing, Inc., Toronto, Ontario, CANADA
Lines: 61

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