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
February 25, 2013 18:57
Re: Getting new version of Pod::Simple updated in core (and fixingupstream modules in general)
Message ID:
On 25 February 2013 16:25, Ricardo Signes <> wrote:
> * demerphq <> [2013-02-25T02:22:17]
>> I am wondering what the status is with getting Pod::Simple updated in perl.
>> [...]
>> However, we have been waiting for those downstream modules to fix
>> their stuff for many months.
> It may be that I have a mistaken grasp of the situation.  My understanding was
> this:
>   1. Pod-Simple had a bug related to hash traversal order
>   2. you supplied a patch
>   3. this patch took a while to get applied
>   4. once it was applied and Pod-Simple released, BinGOs immediately attempted
>      to bring Pod-Simple into perl.git; this was Feb 15: 12c853c41735007
>   5. this was the first time we saw that Pod-Html and podlators would be have
>      their tests broken, so it was not merged
>   6. on Feb 18, I fixed Pod-Html in a branch, waiting for a podlators merge
>      and I contacted Russ about podlators
>   7. on Feb 20, Russ replied that he was sick but would have a look at it soon
> So, I don't think that we're in a situation where we've been waiting for people
> to fix things for months.  Maybe we waited on Pod-Simple for months and we're
> working on two weeks for things downstream of Pod-Simple.
> Am I mistaken?

Well, embarrassingly less than I thought. But a bit. The original
patch was applied three months ago:

The reason I ended up patching Pod::Simple twice, was that I did a
batch of module fixes around three months ago, and I thought they had
all been merged to core, so when I encountered breakage during my hash
traversal randomization changes I assumed it was a new issue and
patched Pod::Simple again. Only to discover it was the same patch that
was applied three months before.

So when BinGOs told me about the reverted upgrade and the related
breakage I assumed that the downstream had known about the issues from
the same time. As your timeline it seems I got that part wrong. For
that I am sorry. And I'm glad I added the PS that I wasnt trying to
"pick on" Pod::Simple, nor any of you all who are working to get that
sorted out. As I said in original mail, my issue is more with the
general problem. In the hash patches ive been doing this has been a
consistent drag on getting my changes merged and integrated.

> I had also assumed -- wrongly? -- that there was plenty of other stuff yet to
> be done in that branch, so that the Pod-Simple related merges alone were not
> blocking you, and that the goal was only to get them done before all other
> blockers were gone.
> If we've reached a point where they're the sole blockers, then by all means we
> can nerf the tests in podlators in blead to get everything else moving.

Pod-Simple is not the only blocker. Module-Pluggable and
ExtUtils-MakeMaker are the other two.

I would prefer releases for all three be merged before I merge, so I
can throw away my "point release versions" without them becoming
"public". (IOW, in my branch I have effectively forked them all.)

Also the number of modules involved illustrates my point nicely. With
those numbers of upstream dependencies the chance that one of them
needs a fair amount of time before they can roll a release becomes
pretty high.

> 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.

To me both of these are obvious expectations but it doesn't hurt to
spell it out clearly as a point of policy.

>> 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.
> My experience has been that this does not help much.  Just being a core
> committer does not indicate that one is going to be around to do this work when
> needed.  I think this policy would add complexity without effectively
> addressing the problem.

Good point.

> I think the previous core-only-patches policy probably addresses the issue.  In
> cases where a CPAN release is required (does this happen?) a more effective
> policy might be at the PAUSE level, something like: the pumpking can authorize
> one-off uploads of CPAN-indexed releases as needed by contacting the PAUSE
> admins.

If we are allowed to make "core only releases" relatively freely
(along with a mandatory patch push and rt ticket) then we can maintain
our development velocity and I will be happy and I imagine the need
for PAUSE admin involvement will be minimal to none.

Maybe I am operating under a misconception, but I thought our policy
was we dont merge changes to cpan modules directly... If we have no
such policy then maybe this whole thread is a waste. If so then sorry.


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