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

Re: dual-lived module development

Thread Previous | Thread Next
Michael G Schwern
February 27, 2007 15:23
Re: dual-lived module development
Message ID:
Yitzchak Scott-Thoennes wrote:
> Tels wrote:
>> As Dave already stated in the past, the home and primary developmen of
>> dual-lived modules is blead.

Uh, what?  No.  As far as I'm concerned the home and primary development of
Test-Simple is CPAN.  I'd say the same thing about ExtUtils-MakeMaker but I
think that would be overstepping my bounds as I am not the original author.

>> Putting them on CPAN serves only two
>> purposes:
>> * so people of current stable Perls can get them earlier and not have to
>> wait for the next stable release to get bugfixes and new features
>> * get the into more wide spread testing of CPAN-testers

That's a very narrow view leaving off the many benefits of decoupling
development from the core.

* The module can be developed without worrying if a failure is the result of
bleadperl or a change in the module.  (This is one of the main reasons I
pulled MakeMaker out, oh god the File::Find and VMS bugs).

* The module can be worked on independently without having to know how to
develop bleadperl (consider Joe Perl User who wants to patch a module).

* Changes to individual modules can be seen and tracked by users as opposed
to having to grovel through a monolithic Changes file for the entire Perl

* Bugs for individual modules can be tracked and seen separate from the bugs
in other modules or in perl.

* There is a distinct person (or group of people) who has
oversight/concern/ownership/responsibility over the code to steer its
development and make sure it actually works.  p5p, being effectively a large
committe, and having so many modules, along with perl itself, to deal with
cannot provide such personal attention.

* Rather than the module adjusting itself to new bugs and quirks in
bleadperl, the modules serve to find new bugs and quirks.  All of CPAN does
this but the dual-lifed modules are explicitly run as part of the bleadperl
tests and thus provide day-to-day coverage.

* Vendors who package perl (Fedora, Debian, etc...) can more easily track
and provide incremental upgrades to core modules without having to track and
pick out the changes from bleadperl and wonder if the new code is backwards

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About