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 07:09

Subject:

Re: Perl 5.10.1

Message ID:

20090630140901.GA33745@plum.flirble.org

On Wed, Jun 24, 2009 at 09:42:51AM -0700, David E. Wheeler wrote:
> On Jun 24, 2009, at 7:20 AM, Nicholas Clark wrote:
> 
> >To make this fly, please help work on figuring out and implementing  
> >automatic
> >smoking of a configurable subset of branches. The smoking doesn't  
> >need to be
> >for all configuration permutations, as most blead smokers currently  
> >do.
> 
> That's a reasonable thing to do, assuming that changes to maintenance  
> branches are inherently conservative (that is, bug fixes and  
> documentation fixes only).

Yes, arguably this was philosophically where I went wrong on the 5.8.x
track. I liked also bringing in as many non-incompatible improvements as
possible, including optimisations and even sometimes features.

However, it's actually also a maintenance burden *decrease* to merge more
over, because the more that is merged, the less the divergence is, and so
the less work that it becomes.

The problem, partly, was, that back in 2003-2005 the release of blead
as 5.10.0 seemed to be forever away, which made it seem likely that the
best way to get fixes into a release was to get them into production.
If 5.12 consistently feels "forever" away, we're not learning from our
mistakes. However, core perl (like anything else on CPAN) does not ship
itself - it needs someone with the time, motivation and sheer force of will
to get it done. 5.8.9 happened in the end because I got pissed off
sufficiently with myself for letting it drag on, that I bloody well did it.
Yes, some people helped. But no-one really wanted it. How many people are
actually using it in production? Versus sticking on 5.8.something-earlier.

There's also a problem of sticking to "bug and documentation fixes" in that
CPAN, well PAUSE, has no concept of such a think. A given module doesn't
have a tree of versions - it's linear, dammit. Plus PAUSE commits
catulofelicide if you upload a different file with the same version number
as an existing file. (A side effect that we do not desire)

So the infrastructure constrains us - there is no facility to have a maint
branch that incorporates only bug and documentation fixes for modules.

[Which is just as much a problem for modules only on CPAN. And happens,
given the grumbling I hear from nearby when certain CPAN modules change
details of the behaviour published APIs]

> >For example, I remember the pain of trying to get Storable to pass on
> >all platforms, when it was added to core. That's a module that was  
> >already
> >on CPAN, and (notionally) widely tested, yet had issues with various
> >exacting platforms. The way I'd see it being done today, under your  
> >model,
> >would be in a branch, which would become merged to core once it was  
> >stable.
> >Hence without preliminary smoke testing of branches, we would not  
> >have had
> >a stable merge.
> 
> This is also a good argument for paring the number of core modules way  
> down so that you have much less of a maintenance nightmare for core  
> Perl itself.

No, it isn't directly. That was a fixed cost of adding a module,
not the ongoing cost of having it present.

Since then, Storable has remained resolutely portable, and hasn't had
problems. Modules which are ongoing pain seem to mainly be those that interact
with the operating system, which is something inherently non-portable.
And unfortunately, most of these are involved in the build process of core
itself, or are part of the toolchain needed to install from CPAN, which
makes them things that need to stay in the core.

However, I'm not arguing against reducing the number of (other) modules in
core. More than that - I've actually figured out what we need to do to do
this, bloody well gone and done that, and am now (I believe, by request)
waiting on 5.10.1 to ship (and juggling other things on my private TODO
list) before going beyond the test case for this (Switch.pm).

> >Again, we had portability issues more recently, when writing shell  
> >scripts
> >to grab the git state and feed it into the right places to show up  
> >in -v
> >and -V output. [The eventual solution to which was "use perl" :-)]
> 
> I hear it's a great little language for that sort of thing. ;-)

There's this minor bootstrapping problem though - you can't be sure you
have a copy of it around whilst you're building it the first time.

Nicholas Clark

Thread Previous | Thread Next