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

Re: Getting new version of Pod::Simple updated in core (and fixingupstream modules in general)

Thread Previous | Thread Next
Craig A. Berry
February 25, 2013 18:21
Re: Getting new version of Pod::Simple updated in core (and fixingupstream modules in general)
Message ID:
On Mon, Feb 25, 2013 at 9:25 AM, Ricardo Signes
<> wrote:
> * demerphq <> [2013-02-25T02:22:17]

>> However, we have been waiting for those downstream modules to fix
>> their stuff for many months.

Welcome to my world.  I have more than once done exactly what you just
did, i.e., fix something I'd already fixed but had forgotten I'd fixed
it.  I have had to mentally subtract blead test failures that I know
I've long since fixed but the fix is sitting upstream somewhere.  I've
had to reapply patches to blead because a new upstream release didn't
include my changes and was blindly integrated into blead without
anyone noticing that blead had diverged.

All of which is to say, I feel your pain, and I do hate to see
anything slowing down / demotivating someone who's been doing as much
as you've been doing lately.  I'm not so sure I know what the solution
is, though.  I think the current dual life mechanism is a compromise
and it's entirely possible that there is no better compromise we could

> Now, on to the general suggestion:
>> I think our policy should be: push patches upstream. Wait a week. If a
>> new release is not forthcoming create a core only release of the
>> module.
> Maybe, iff we have a RT ticket in pointing to a ticket in the
> project's bug tracker.  Also, we need to be careful about core only releases.
> We never want them to contain any changes other than fixes to make things work
> on blead.

That kicks the can down the road a bit, but when it's time to release
Perl and we're using a dev version of the module, then we have other
problems.  I suspect in many cases it would be better to integrate the
tip of the module development stream and add our changes to that; then
there would be fewer changes (possibly only a version bump) later when
there is another release of the module.  It really depends on where
Perl and the module are in their respective release cycles.

If all dual-life modules had development and maint branches the way
core does that would help a lot, but they don't, and I'm not sure we
can make them do that.

>> I also think that our policy should be that if you have a module in
>> core you have to give more than one core committer a commit bit so
>> that they can roll releases if needed.

Strictly speaking I think it's PAUSE access that matters as that's
what you need to issue a release.

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