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
From:
demerphq
Date:
February 25, 2013 12:26
Subject:
Re: Getting new version of Pod::Simple updated in core (andfixingupstream modules in general)
Message ID:
CANgJU+Wj3_cfAFyWwjh37JsWM+mYKijWBZ79aTbm0bqykA2fFg@mail.gmail.com
On 25 February 2013 12:48, James E Keenan <jkeen@verizon.net> 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.

Yves
[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


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