develooper Front page | perl.perl5.porters | Postings from February 2009

Re: deprecating and removing core modules (was Re: RFC: Providing An Alternative to File-Find in the Perl 5 Core?)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 18, 2009 07:56
Subject:
Re: deprecating and removing core modules (was Re: RFC: Providing An Alternative to File-Find in the Perl 5 Core?)
Message ID:
20090218155631.GN81285@plum.flirble.org
On Wed, Feb 18, 2009 at 08:28:03AM -0700, Tom Christiansen wrote:

> Hadn't the dual-life modules where the CPAN maintainer, not p5p,
> been created to make easier the inclusion of modules without
> increasing core workload?
> 
> Could this then be part of your paring approach?  Making them 
> dual-lived?

Specifically I want to get Switch.pm, out of the core.

It's already dual lived. It doesn't help that the CPAN maintainer is now
Rafael. He only took that over because Damian had no time to deal with it.

We want to find a way to remove code from under the noses of people who
(just) install the core distribution, the sort of people who are too
$whatever to read documentation that says "please don't use this", but
aren't too $whatever_else to later report bugs in it. (Or aren't the same
person as the one who committed their codebase down the path of using old
stuff)


Dual-lifing hasn't proven itself to be a long term solution to this.
There's added friction for us keeping track of "our" upstream, and we
still run the risk the the person who kindly volunteered to accept the
dual life maintenance later goes away. This actually relates to the third
reason that people press to get things into core, one I wasn't aware of
until a year or so ago (and I forgot who, here, described it to me)


People push to get things into core because

1: The Perl core is already installed. But they can't get approval to install
   other modules from CPAN.

   [Bad programmer. You're trying to burden someone else with a long term
    technical problem because you've failed to address your local political
    problems]

2: They perceive modules in core as being "blessed" - if it's there it must
   be better than all the competitors on CPAN]

   [Bad programmer. Historically things have only ever been added to the core.
    Reasons for its addition *at the time* may not be as clear cut as you
    infer, and there may now be a better solution. You're trying to burden
    someone else with a long term technical problem because you're falsely
    lazy, excessively inpatient and insufficiently hubristic to devise your
    own criteria for selecting the right module for the job]

3: They perceive modules in core as being "supported" - if it's there, it will
   be looked after for ever.

   [Bad programmer. You appear to think that the mere mortals *volunteering*
    to maintain the core are of a difference species than the mere mortals
    *volunteering* their code to CPAN]


   CPAN is the language, Perl is just its syntax -- Audrey Tang

[I blame Jarkko. It's all his fault. When I told him this, he just smiled]


The punch line of the Irishman Giving Directions joke applies here:

  If I were you sir, I wouldn't start from here.


With hindsight, if I were starting again, the only things that would be in
were modules needed to build the core, and modules that facilitate obtaining
and building modules from CPAN.

Nicholas Clark
    

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About