Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
David E. Wheeler
Date:
June 24, 2009 09:19
Subject:
Re: Perl 5.10.1
Message ID:
3EB7CFE2-6E3F-443D-83BF-E73457FB8705@kineticode.com
On Jun 24, 2009, at 2:34 AM, Nicholas Clark wrote:
> On Tue, Jun 23, 2009 at 07:27:40PM -0700, David E. Wheeler wrote:
>
>> That leaves out those of us who detest packaging systems, and hate
>> having to maintain scripts that apply patches, constantly having to
>> decide what patches we need and what we don't for production.
>
> But you are not in the majority.
And as you pointed out in your use Perl post, it seems that users of
RHEL in particular suffer because they're not in my minority.
OTOH, if we had more frequent stable releases, I should think that
this problem would be reduced. I miss the days you were doing a
release every quarter!
>> Only a fool would upgrade a production box to a new release and
>> completely replace the existing version in the process. One typically
>> installs it in a completely separate root, and if it fails, you
>> delete
>> that version without any effect on the installed version. Any admin
>> of
>> average skill can do this, and should.
>
> Which, it seems, it why vendors stick to exactly the release that they
> first packaged on an OS.
Yeah, see darwin. Jesus.
> /usr/bin/perl on my OS X 10.3 machine stayed at "5.8.1 RC3" for its
> entire
> life. On every Unix system that I have access to, /usr/bin/perl is
> still
> 5.8.8, even though it's 6 months since 5.8.9 shipped, and it's a
> seamless
> upgrade incorporating a lot of bug fixes.
Yet another reason not to use distribution packages. They are *always*
hopelessly behind. It drives me batshit.
> At all the companies I have worked for, upgrading the production
> perl has
> not been something undertaken lightly. In all bar two it was outside
> the
> development department's control. In the two where it is, it's still
> not
> something done lightly, because it's so low down the dependency chain.
Exactly.
> In a controlled environment the risk isn't of catastrophic failure,
> as that
> can be backed out quickly. It's the risk of subtle bugs, the
> implications of
> which aren't discovered for a while, by which point enough has been
> built
> that subtly depends on the new release that it's as much of a risk
> rolling
> back as pressing forward. As a specific example, the BBC took years to
> migrate from 5.004_04 (note, _04, not _05). And even now, I think
> that the
> "official" production perl is 5.6.1.
But that's a problem no matter what you do. If I upgraded from 5.8.8
to 5.8.9 in a production system now, and everything seemed to work
well, and it was only a month after it went to production that we
discovered subtle bugs, how long would I need to wait for 5.8.10
before it could be fixed?
Honestly, more frequent releases better address this problem.
> Many end users, like it or not, are using the vendor supplied perl.
> Be that
> an OS vendor, or the internal vendor in their company. And, like it
> or not,
> many vendors package up whatever is current, and stick to that. So
> if there
> are frequent, slightly dodgy releases, we end up with an ecosystem
> of many
> dodgy releases, each with different bugs to work round. And a
> reputation for
> slighty dodgy releases. And upgrade roulette - gambling that the new
> release
> will not introduce bugs worse than the bugs that it fixes.
As RHEL has shown, the Perl core cannot and should not be held
responsible for a vendor's dodgy releases. When there are frequent,
regular stable releases, someone who complains about a buggy vendor
install can just be told that it has been fixed in core and release in
5.x.y. If the vendor doesn't support it, then the user bitches to the
vendor or compiles from source.
Look, I'm not trying to be snarky here, and I'm clearly a P5P newcomer
(though an oldcomer with Perl itself!). So maybe I'm just dead wrong.
It's entirely possible (my wife will tell you it's frequent). However,
I have not been convinced by the discussion so far. AFAICT, more
frequent stable releases will better address the points you've raised
than infrequent stable releases.
Best,
David
Thread Previous
|
Thread Next