Front page | perl.perl5.porters |
Postings from February 2023
On Tue, 28 Feb 2023 at 12:22, sisyphus <sisyphus359@gmail.com> wrote: > On Mon, Feb 27, 2023 at 9:17 PM demerphq <demerphq@gmail.com> wrote: > >> There seems to be this idea that if we deprecate something that we have >> two release cycles, IOW, two *years*, before we have to get stuff fixed, >> and that the only code which might be broken by the deprecation is code >> that use fatal warnings, which we generally advise people not to use. >> > > IMO, in this case a suitable fix is to have the fatality of the warnings > disabled. > That is still a change we or the author have to make to the distribution. If the author is AWOL, then the toolchain is broken for that release. > > >> But that isn't correct. Odds are *very* likely we get CPAN breakage from >> the very moment we deprecate something, as many modules test to see if they >> generate warnings when they run. This can be transitive breakage with >> "action at a distance", where distribution A uses B uses C used D which >> uses a deprecated feature, and only A actually fails test because it tests >> for warnings but B and C and D do not. >> > > IMO, in this case a suitable fix is to have distribution A's test suite > modified to accept or ignore the fact that module D presented a deprecation > warning. There's no need to modify module D. > That is MUCH easier said than done. It is generally much easier to fix D than to fix A to ignore that specific warning. (IMO) > > Is that about it ? > Are there any other scenarios we need to consider at this stage? > The main point is that we need to do something, immediately. When I brought this up on #p5p irc I got a lot of pushback that we have two years. The point of this mail is that we don't. From the moment we release the deprecation warnings the CPAN river is impacted. If amodule is high up in the river and doing what i think many would consider "responsible testing" and validating their code runs warning free then the distribution will be broken, even if strictly speaking the code is just fine albeit noisy with deprecation warnings. > > The first thing to do would be to file bug reports against the affected > modules - ie either because they fatalize warnings, or because their test > suite overlooked the possibility of "action at a distance". > After that, what we do depends upon whether the registered maintainer > co-operates, or responds but won't co-operate, or doesn't respond. > Sure, but it is still a BBC. We still have to do something. We can't just pretend we have two years to go before we can do something. Until it is actually fixed upstream the dependency is broken from a CPAN perspective. > Have the changes that trigger these issues already been merged into blead ? > Yes. One is already released in 5.37.9, and one will be released with 5.37.10 and is present in blead. > If so, I'll start checking the distros listed at > https://github.com/Perl/perl5/issues/20863 in the next day or so, and > file bug reports about the impending changes as appropriate. > Is that a sane way to start ? > Yes indeed. Although I have already filed bug reports (and patches) for a lot of Father Chrysotomos'es modules (aka SPROUT aka @cpansprout), he was a proud (ab)user of apostrophe as a package separator. I have not fixed all of them however, the ones lower down in the river rating on metacpan I have not checked. It would be nice if we could get that list regenerated by author. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next