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.) > > The main point is that we need to do something, immediately. > Then let's get started filing bug reports. 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. 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 ? Cheers, RobThread Previous | Thread Next