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

RE: Getting new version of Pod::Simple updated in core (and fixing upstream modules in general)

Thread Previous | Thread Next
Steve Hay
March 1, 2013 18:09
RE: Getting new version of Pod::Simple updated in core (and fixing upstream modules in general)
Message ID:
Dave Mitchell wrote on 2013-03-01:
> On Mon, Feb 25, 2013 at 08:22:17AM +0100, demerphq wrote:
>> I think our policy should be: push patches upstream. Wait a week. If
>> new release is not forthcoming create a core only release of the
> We used to have a policy where we freely patched in core, modules that
> were dual-lived. It ended up being chaos, with 100+ modules gradually
> getting out of sync with CPAN. The main problems are:
> 1) There is a risk, each time a new CPAN release is pulled into blead,
> of overwriting any local fixes. Failing that, someone has to examine
> any local fixes, and make sure that they're (correctly) re-applied
> over the new CPAN release (while skipping any local changes that
> *have* been incorporated back into the CPAN release, but perhaps in a
> different way).
> Which can be quite hard.
> 2) On each perl maint branch, you end up with with a separately-forked
> unofficial version the module, all out of sync with each other, and
> with inconsistent _00N ad-hoc version numbers. That was the situation
> I found myself in as maint-5.10 pumpkin; it took weeks and weeks of
> effort to try and work out what was going on for each of 100+
> distributions. It's not nearly as bad these days because we try to
> avoid patching or upgrading distributions in maint releases where
> avoidable, and we now have a bunch of tools like core-cpan-diff that
> can more easily flag up divergences.
> So I would suggest: only patch locally if the change is critical for
> core perl to build/function correctly, and the module's author has
> failed to provide a new release within a "reasonable" period. Then
> work hard to resync core and CPAN ASAP.

This is the policy already clearly set out in perlpolicy.pod, and I also
strongly agree with it, having previously experienced the nightmare of
trying to upgrade too many out-of-sync CPAN distros in blead, especially
when making blead releases. I can well imagine it's even more of a trial
when making maint releases.

It is the only way to preserve whatever sanity the pumpking and release
engineers have :-)

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