Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: Nicholas Clark
June 20, 2009 14:43
Re: Perl 5.10.1
Message ID: 20090620214309.GB33745@plum.flirble.org
On Sat, Jun 20, 2009 at 01:05:18PM -0700, Jonathan Leto wrote:
> As an exercise, I checked out the perl-5.10 git tag and then
> cherry-picked Rick Delaney's "Big slowdown in 5.10 @_ parameter
> passing " commit . I ran all the tests and they pass on my machine.
> Obviously a bit more smoke testing is needed, but I took this as a
> good sign.
> This is in response to chromatic's comments :
> Is pointing out that a patch for a known performance regression
> languishing, unreleased, in bleadperl for 17 months a problem? Is that
No, not a problem.
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.
> criticism dismissible from everyone who isn't currently a Perl 5
> committer or the maintainer of a core module?
No, it's not being dismissed.
> I think that releasing Perl 5.10.1 with only this change is very
> valuable to the Perl community, so I went and tried to help it along.
> Is this a viable option?
1: There would be a lot of stick about "17 months, and that's *all*?"
2: I think it would be unwise - 5.10.0 contains a defective smartmatch
implementation that we want to kill before it takes hold.
(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.)
Rightly or wrongly, there's a superstition about installing .0 releases.
(extrapolated logically, that will mean that .1 will become the new .0,
then .2 the new .1 is .0)
We have the fixed smartmatch - merge that too.
As is, currently, this is not the route that Dave wants to take. I'm not Dave.
It's not my call. If I understand Dave's view correctly, he'd like to triage
the following bugs before going to RC1:
So would definitely be helpful to getting Dave to ship 5.10.1 would be to
look through that list of bugs, and pick off any they feel able to make
progress on. Progress includes any of
1: Verifying that the bug is still present in blead
2: Writing a test that will pass once the bug is fixed
3: Using that test to run a bisect to find when the bug was introduced
4: Actually fixing the bug
Obviously number 4 is the goal, but even getting to number 2 is useful.
Some bugs are already bisected.
Note also, that's not an exhaustive list.
RT's statuses don't record that there's no need to look at 60574 and 65582,
because I believe I know how to fix them. (Just no tuits yet)