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

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

Thread Previous | Thread Next
Nicholas Clark
March 2, 2013 10:04
Re: Getting new version of Pod::Simple updated in core (and fixingupstream modules in general)
Message ID:
On Fri, Mar 01, 2013 at 06:08:55PM -0000, Steve Hay wrote:
> 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
> 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

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

> > 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 :-)

This is also why I think that it's a really good thing that we have a lot
more people making releases.

Until you get to make a release, you usually don't get to experience all
these sorts of pain points, which makes it a lot clearer why some of the
process and policy has ended up the way it is.

I'm definitely not saying that it's perfect. Nor should it be considered
immutable. But when you get to make releases, you get to see some of the
other sides of the trade offs needed.

Nicholas Clark

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