Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 20, 2009 23:49

Subject:

Re: Perl 5.10.1

Message ID:

20090621064932.GC33745@plum.flirble.org

On Sat, Jun 20, 2009 at 06:44:52PM -0700, chromatic wrote:
> It would be my pleasure to write a short note for the perldelta or
> README or both to explain that the semantics of 5.10 and 5.10.1 smart
> matching are changing in certain circumstances.  Would that suffice to
> notify reasonable people that Perl 5.10.1 does not further entrench
> behavior already changed in bleadperl?  (I don't care about unreasonable
> people -- they're unpleasable.)

Thank you for your kind offer. However, I notice that such a note has already
been written:

http://perl5.git.perl.org/perl.git/blob/maint-5.10:/pod/perl5101delta.pod#l43

> On Sat, Jun 20, 2009 at 10:43:09PM +0100, Nicholas Clark wrote:
> 
> > However, in return, I'd like to point out that if the Perl community *had*
> > tested 5.10 before release, they would have spotted this speed regression,
> > so to some extent they are getting what they deserve.
> 
> Anyone who believes that release candidates get any sort of exhaustive
> community testing is either dangeriously naive or hasn't paid attention
> to the negligible amount of testing release candidates do get.

Or didn't arrange it themselves. Which is why Matt Trout will be ensuring that
this time the core Catalyst community thoroughly test this one.

> >    (Again, if the Perl community had tested this in the *year or more* before
> >     blead became 5.10.0, it would have been spotted in time.)
> 
> I don't understand this argument.  How is it okay for a pumpking to hold
> back a release to punish the filthy proles who caught and fixed a
> performance regression a couple of weeks on the wrong side of a release,
> because cherrypicking patches to make a release is difficult (even if
> someone else has just done all of the work, like pumpkings always beg
> someone else to do), because regressions are so difficult that long

Cherry picking is not always hard. Nor is responding to individual bug reports.
Sometimes it's hard. But

a: it mounts up if you don't keep on top of it
b: the amount of time and mental effort taken to complete a task can balloon
   beyond the amount of time you had available in a stretch (for example an
   evening)

at which point you hit a demoralising road block, if you're a volunteer, and
all you have is odd evenings and time you "borrow" from work.

I'm not convinced that a decentralised cherry-picking system done as pull
requests is the way to go. However Best Practical have been writing a
commit tagging system for the explicit purpose of decentralising the initial
work of writing a perldelta, and partitioning "compatible" and "incompatible"
changes. I'm not sure what the state of that is - I believe currently it's
being alpha tested by some people outside Best Practical.

Nicholas Clark

Thread Previous | Thread Next