Front page | perl.perl5.porters |
Postings from March 2013
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 a > new release is not forthcoming create a core only release of the > module. 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. -- Lear: Dost thou call me fool, boy? Fool: All thy other titles thou hast given away; that thou wast born with.Thread Previous | Thread Next