Re: Perl 5.10.1

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

Thread Previous | Thread Next

From:

David E. Wheeler

Date:

June 30, 2009 09:09

Subject:

Re: Perl 5.10.1

Message ID:

AFF5B7F7-133A-4D86-9FC2-8F9C17066E26@kineticode.com

On Jun 30, 2009, at 7:09 AM, Nicholas Clark wrote:

> 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.

Yes, and I was in favor of more stuff in the core back then. Live and  
learn, eh?

> 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.

Yeah, it's the dual-life modules that are more the problem, it seems  
to me.

> 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.

(Nicholas Clark)++ # You're a one man releasing machine!

> 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)

Again, this is an issue with dual-life modules, it seems to me. If  
they are in core and not maintained elsewhere, you don't have a  
synchronization problem and can thus just have bug fixes and  
documentation updates in minor releases.

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

Right, unless dual-lived modules could be removed from core and put  
into their own stdlib-type distribution, instead.

>> 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.

So now perhaps modules like Storable should be kept in core (I can see  
a case for Storable being an important core module) but removed from  
CPAN. Again, no more dual-life-ing is the idea.

> 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.

Yes, agreed. But not on CPAN. Once they're fixed in core, they should  
stay there, be pulled as separate distributions from CPAN, and just  
maintained for bug fixes and such in release branches, with new  
features and improvements added only to blead.

> 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).

How can I help you with this?

>> 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.

Isn't a miniperl first compiled for that?

Best,

David

Thread Previous | Thread Next