Front page | perl.perl5.porters |
Postings from April 2010
Hi Ricardo, hi all, Ricardo Signes wrote: > That's all. I'd like to move ahead with getting a new Pod-Simple out the door > and fixed in core, so I was just hoping for a "yes, that's reasonable" or "no, > never import a new real release to core." Thanks. I think it's reasonable. I'd even go one step further than what I understood from your reasoning: If there's an existing release of a dual-lived module that fixes a bug we'd like to see fixed in core, and that doesn't change *the world*, then we should seriously consider pulling it into maint as a whole. As I see it, we have the following general options in such a case: 1) Strict no. Cherry-pick bug-fixing changes and assign an intermediate development version. 2) Consideration of each case. If the available new release fixes the bug and isn't fraught with peril, pull it in. Otherwise ask upstream to make an intermediate release we can pull in or -- as a fallback -- do the cherry-picking & dev-versioning thing. 3) Upgrade all dual-lived modules in maint. Obviously, 3) is out by policy and that's a good thing. Regarding 1), I think every case where we violate the Porting/Maintainers.pl (yes, in maint, not blead) designation of "upstream" by changing an "upstream => cpan" module in core, we're creating really annoying pain down the road. This is lessened to some extend by the fact that in future, we won't have 9 releases of any stable series and thus the pain has a naturally limited scope. I think 2) is actually the safest approach: Try to get everything right by having upstream make an intermediate release that we can point to. In the not-unlikely case that this fails due to not-so-responsive upstream maintainers, we can always fall back to pulling in minor new features (after case by case decision from the pumpking) or more crude patching. --SteffenThread Previous | Thread Next