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

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

Thread Previous | Thread Next
February 25, 2013 12:26
Re: Getting new version of Pod::Simple updated in core (andfixingupstream modules in general)
Message ID:
On 25 February 2013 12:48, James E Keenan <> wrote:
> On 2/25/13 2:22 AM, demerphq wrote:
>> Hi all,
>> I am wondering what the status is with getting Pod::Simple updated in
>> perl.
>> As far as I can tell some changes to Pod::Simple caused some
>> downstream breakage and we have not upgraded because of it.
>> I understand Ricardo was looking into fixing one of the breakages, in
>> which case all the better.
>> However, we have been waiting for those downstream modules to fix
>> their stuff for many months.
>> I don't think is a reasonable amount of time.
>> IMO at this point we should just update Pod::Simple and let the
>> maintainers start seeing test fails in their cpan matrixes.
>> I actually think the are grounds to rethink our policies about dual
>> lifed modules. It is very very hard to maintain development velocity
>> when you have to wait weeks to get upstream packages fixed and are
>> blocked from merging only because of upstream modules not applying
>> patches that took minutes to write. It is even more difficult when you
>> have to wait on modules that are downstream of upstream to patch their
>> stuff too. IMO This is not good for Perl. Developer velocity is
>> important, being slammed to a stop because of upstream issues is
>> really frustrating.
>> 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.
>> 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.
>> This waiting forever to get minor test patches applied to upstream is
>> really frustrating.
>> Yves
> While I haven't been following these issues closely, my general sense is
> that we do have a problem in this area and so discussion is warranted.

Thanks, that makes me feel a bit less like a Cassandra. :-)

> But, could you clarify what you mean by "upstream" and "downstream" here?  I
> thought the only situation we had to worry about was "upstream is 'cpan'".
> I'm not sure when or where we have to worry about "downstream".

Take Pod::Simple. It has for months included a patch that makes it
robust to the hash randomization changes that I did. So long that I
actually forget the first request, and filed a second, thinking it was
a different issue. Turned out both patches were pretty much identical,
and the first had been in Pod::Simple for ages.

Unfortunately the version that included my patch included other, IMO
relatively non-controversial changes[1], to the Pod::Simple output.
These change the caused modules that depend on Pod::Simple to break
tests. As far as I could tell the breakage is cosmetic, test specific,
and related to modules downstream from Pod::Simple doing "snapshot"
style testing. IOW, write code that prints some arbitrary output to a
file, then write a test that checks that if you run it again it
produces the same output. Such testing is of course fragile and
sensitive to minor changes like that ones in Pod::Simple.

So in my discussion Pod::Simple is "upstream" from us, but the modules
which break are downstream from it.

And in this case we have been effectively blocked from updating
Pod::Simple in core because if we do then all the Pod packages that
depend on it fail tests.

[1]: Removing non alpha-numeric values from element ids.
ps: Id like to be clear that I am not picking on Pod::Simple, indeed,
the author was very responsive with my patches, nor really the modules
downstream from it. I understand that there may be visibility issues
involved, and I known that people, including Ricardo, are working on
resolving the issues in this dependency chain, and I certainly wouldnt
want to demotivate their efforts by a perception of picking on them. I
only mention it because it happens to be pertinent to my current
frustration and illustrates the general problem nicely.

perl -Mre=debug -e "/just|another|perl|hacker/"

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