Re: Perl 5.10.1

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

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 30, 2009 08:00

Subject:

Re: Perl 5.10.1

Message ID:

20090630150027.GC33745@plum.flirble.org

On Wed, Jun 24, 2009 at 05:48:45AM -0400, David Golden wrote:
> On Wed, Jun 24, 2009 at 1:08 AM, David E. Wheeler<david@kineticode.com> wrote:
> > On Jun 23, 2009, at 8:39 PM, 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.
> >
> > This may well fracture Perl. I'm already looking to go with Perl5i when
> > Schwern & Co. decide to "release." Do you want more of those?
> 
> It may.  But that's part of a broader debate about speed of evolution
> versus stability.
> 
> I'm talking about something much narrower.  Rafael suggested a library
> of "important" patches for those who need them.  I'm taking that one
> step further and saying it doesn't have to be patches -- it can be
> full-fledged, ready to compile source trees.
> 
> Moreover, it can happen entirely to the side of p5p.  This is a good
> thing for those who want a fix that isn't blessed/sanctioned.

Yes.

> My example of getting ancient perls to build on my system is an
> example.  If I want to be able to test my distros against every major
> perl release, I don't want to have to patch every single one of them
> to get it to build.  p5p didn't like my idea of adding "maint-5.X.Y"
> branches to backport build-fixes for "perl-5.X.Y" branches.  I forget
> why -- probably something about not implying that anyone is supporting
> those older releases or something.  Ok, fine.  I don't really care to
> waste my time on that argument and I don't need to because I don't
> need it to be in the official repo -- it's in mine.

IIRC I didn't say it at the time, but that was my view - I don't want any
implication that these are official branches. It is useful that a way
exists for CPAN authors and others trying to test against specific releases
to collate build fixes to get *superseded* perls to build on the moving
target that is an OS, but that goal is met with a branch anywhere public
and accessible.

I don't want OS vendors or others seeing such branches and assuming that they
can download and install them, and then we'll be happy to answer questions
about an install they made last week of a version that was released years
ago. We do sometimes get questions to this list from people trying to install
older versions, and whilst we can and do reply to them asking then "why?"
(and telling them that we're not going to answer except on what's current)

a: even that takes time
b: it still wastes their time if they even start down this route.
   like it or not, they (or their PHBs) are going to attribute problems to
   "Perl", not to the face in the mirror.

So my view is the earlier that we can kill it (and the more dead it is) the
better.

Nicholas Clark

Thread Previous | Thread Next