Front page | perl.perl5.porters |
Postings from February 2023
On Tue, 28 Feb 2023 at 14:06, sisyphus <sisyphus359@gmail.com> wrote: > On Tue, Feb 28, 2023 at 10:38 PM demerphq <demerphq@gmail.com> wrote: > >> On Tue, 28 Feb 2023 at 12:22, sisyphus <sisyphus359@gmail.com> wrote: >> > . >> >>> 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) >> >> > > Ok - file bug reports against both A and D. > Fixing it in D will suffice, but A is still doing the wrong thing (IMO) by > failing the tests because a warning was given. (Essentially, A's test suite > has made warnings fatal. > I can see the argument, but i can also see the counter argument; that people want to test that their code functions correctly and is warning free. Modules like Test::Warn wouldn't exist if this weren't a common practice. I don't think we will get a lot of traction telling people not to do it. Maybe Test::Warn should know to ignore deprecation warnings except when AUTHOR_TESTING is true. See https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lancaster-consensus.md Even then i can see people arguing that one either way. Regardless for perl5-porters, i believe our position is we take responsibility if something we do breaks something on CPAN, even if really it shouldnt have. Hyrums law in a nutshell i guess. https://www.hyrumslaw.com/ > >> >> The main point is that we need to do something, immediately. >> > > > Then let's get started filing bug reports. > I have, and I have been filing patches too. > The sooner we start, the sooner we find out whether a module has a > responsive maintainer or not, ... and the sooner we find out exactly what > we need to do. > Agreed. It is also something that you get faster at the more you do. > For mine, if the module's metacpan page specifies a github "Repository", > I'll check whether an issue has been raised there - and raise one if it > hasn't. > If there's no github repo, I'll check rt.cpan.org and file a report there > (unless one has already been filed). > Of course, prior to that, I will check that the issue does in fact exist > ;-) > > Is that how to start ? > Yes, I think so. I generally check the "repository" link on metacpan.org, and then if its not there, the "issues" link. Some things on CPAN seem to point at RT even though they have a github repo with an Issues tab. If they have a repository link i tend to clone and fix and then push PR instead of filing a bug report. But maybe that isnt the right thing to do. James might have some additional thoughts on that, historically he has done a lot of the BBC coordination and cat-herding. Cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next