Re: Perl 5.10.1

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

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 24, 2009 02:17

Subject:

Re: Perl 5.10.1

Message ID:

20090624091701.GP33745@plum.flirble.org

On Tue, Jun 23, 2009 at 10:17:20PM -0700, chromatic wrote:
> On Tuesday 23 June 2009 20:39:21 David Golden wrote:
> 
> > So in my opinion, we need a way for people to publicize useful
> > branches they maintain and we need an easy way for an admin of average
> > skill to easily build and install a perl from an arbitrary git branch.
> 
> That sounds like an affordance for an admin of average skill (is that code for 
> "doesn't follow p5p closely"?) to believe that a big wad of code vetted for 
> stability, utility, and correctness even less often than bleadperl has the 
> patina of support, or at least official tolerence.
> 
> The existence of people willing to tolerate those kinds of antics to get 
> useful features and necessary patches indicates something very important about 
> the release process... especially considering the kind of abuse Red Hat 
> received from p5p for pulling a patch which turns out to have caused a 
> performance problem in a small but measurable subset of significant programs.
> 
> (Careful readers have noted more than a hint of irony in the previous 
> sentence.)

And an avoidance of discussing precisely *why* they got slated - for making
a sequence of mistakes, compounding the problem, and not learning from it.

For the avoidance of all doubt, here is a reprint of my considered opinion
from http://use.perl.org/~nicholas/journal/37274

    "Your random blog" has never been the right place to report a
    bug[1]. So to keep with the spirit, here's a fix to a bug, reported
    on my random blog.

    It seems that there is still a problem with RedHat's packaged perl
    5.8."8"[2]. RedHat seem to have an aggressive policy of
    incorporating pre-release changes in their released production
    code. This would not be so bad if they actually communicated back
    with upstream (i.e. me and the other people on the perl5-porters
    mailing list), or demonstrated that they had sufficient in-house
    knowledge that they didn't need to. But evidence suggests that
    neither is true, certainly for 5.8.x[3]

    Let me stress that there has never been this problem in any released
    Perl, 5.8.7, 5.8.8, 5.10.0, and it won't be in 5.8.9 either when it
    comes out. The problem was caused by changes I made in the 5.8.x
    tree that RedHat integrated. End users reported the first bug
    something like 2 years ago, and RedHat closed it as "upstream patch"
    rather than reporting back "you know that pre-release change you
    made, that we integrated - well, it seems to have some problems". So
    I fixed the cases I was aware of.

    I'm human, and it turns out that that it wasn't all the cases. Once
    I was made aware of this (by a RedHat user, note, never the RedHat
    maintainer) I fixed the problems he reported, and went on a 2 day
    trawl of CPAN[4] to locate every other idiom that was going to be a
    problem.

    For their versions affected, RedHat merely need to put out a patch
    integrating changes 31996, 32018, 32019 and 32025 which FIX IT, are
    documented as FIXING IT, and are from NOVEMBER 2007.

    Works on my machine. And anyone else's machine who is running my
    code. Particularly my released code.

    Although, the better fix is not to use the vendor's Perl release for
    your production systems. Render unto Caesar the things which are
    Caesar's and for yourselves, compile your own, and your own module
    tree, from source you keep and control in your own version control
    system, which changes only when you change it. In particular, if
    you're not using ithreads anywhere you should compile without
    ithreads support, which most vendors choose to enable. (It's not the
    default, and it costs about a 10% slowdown). Anyone doing this would
    never even have known that there was a problem with some vendor's
    interpretation of perl.

    Update

    No, it's still broken in RHEL5. root had changed everyone's $PATH
    ("it is my machine, after all"), and in my haste I'd not realised
    that I actually just typed perl, not /usr/bin/perl. So to be fair
    they are still asleep on the job. Where's I'm awake and doing this
    stuff for free.

    [1] Nor is your bug tracker. Upstream's own bug tracker is the O(1)
    place where upstream reads about bugs in upstream's own
    software. Not O(n) other people's bug trackers. The latter does not
    scale.

    [2] At least in some of their distributions. The only RedHat box I
    have access to, and that's an account created 3 minutes ago, is "Red
    Hat Enterprise Linux Server release 5" and their supplied
    /usr/bin/perl doesn't have the bug.

    [3] It has been a different matter for 5.10.0 in Fedora. For that,
    the maintainer has been very communicative, and so we were able to
    help him fix problems and get Perl 5.10.0 into Fedora Core 9.

    [4] This was when I had a lot more free time than now, mainly
    because I was having a break between jobs.


Nicholas Clark

Thread Previous | Thread Next