develooper Front page | perl.perl5.porters | Postings from March 2014

Re: [perl #121510] [Request for freeze exception] Fix for Carp.pmbotched metadata CPANRT#88494

Thread Previous
March 30, 2014 10:09
Re: [perl #121510] [Request for freeze exception] Fix for Carp.pmbotched metadata CPANRT#88494
Message ID:
Peter Rabbitson wrote:
>The current maintainer rejected multiple offers for help with release,
>citing he needs to find time to (allegedly) deal with the still unresolved

That's a mangled version of what happened.  I have not been looking to
do anything with [ #72467], as that's a direct product of
the lack of refcounting of the stack, and there's no prospect of a clean
workaround in Carp.  I was, however, hoping to fix the $! localisation
problem [ #88545], which arises from core bug [perl #119683]
and *is* potentially workaroundable.

As for rejecting offers of help, note that Carp is blead-upstream, so
I'm not actually its maintainer, only the vehicle for the downstream
CPAN release.  If help is supplied in the form of patches it can go
through any core committer.  I have done upstream work on it in recent
versions, but Carp is not my exclusive territory.

>A day ago Carp 1.33 was released, which fixes only RT#88531, without doing
>anything about RT#88494. The maintainer dismissed a plea to fix this on
>irc #p5p with "it's annoying, but blead is in freeze".

[ #88531] was fixed upstream back in October by ether, and
the Carp version number was belatedly bumped early this month by BinGOs.
What happened a few days ago was not the fixing of the bug, but merely
the release of the CPAN incarnation.

I had the tuit to work on Carp, but due to the freeze, I wasn't free
to fix [ #88494].  I was constrained to merely doing a CPAN
release of the previously-done upstream work (just the [
#88531] fix).  The only fix really achieved by the release per se was
of [ #88699], a trivial fault in the Changes file, which is
almost the only part of the CPAN release that's actually specific to CPAN.

>I am requesting an exception to the freeze policy so this can be addressed

I think it's a reasonable exception to make.

>* A changelog entry (because the current Changelog is versioned by the
>  maintainer in a *private* repository)

That's not an incompleteness from the point of view of a core patch.
Updating the Changes file is part of my work in preparing the CPAN

>* A Module::Corelist update

That's also not an incompleteness for a core patch.  Updating
Module::CoreList is part of the work in preparing a core release.

>                            because it is unclear how/if a new Carp 1.34 can
>  be shipped to CPAN

This is irrelevant to Module::CoreList, which records what the core
distribution contains, independent of separate CPAN releases of the
modules that it lists.

>-use parent -norequire => 'Stringable';
>+use base 'Stringable';

This patch replaces one undeclared dependency with another.  That's not
a fix.  The fix is to declare the dependency in Makefile.PL.  Or,
possibly, to remove the Makefile.PL from the core entirely, as it seems
to be covered by the core's defaults.  If the core had no Makefile.PL
then I would necessarily maintain one separately for the CPAN releases,
and fixing bugs in it would not be impeded by core freeze.


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