develooper Front page | perl.perl5.porters | Postings from February 2023

Re: Deprecation doesn't mean we have two release cycles beforethings break.

Thread Previous | Thread Next
February 28, 2023 13:41
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
On Tue, 28 Feb 2023 at 14:06, sisyphus <> wrote:

> On Tue, Feb 28, 2023 at 10:38 PM demerphq <> wrote:
>> On Tue, 28 Feb 2023 at 12:22, sisyphus <> 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.


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.

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


perl -Mre=debug -e "/just|another|perl|hacker/"

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