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
From:
demerphq
Date:
February 28, 2023 13:41
Subject:
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
CANgJU+W3fXva4R1-ret-p2jjZZK9a6MJNcwNXo5wCKBtQsTa3g@mail.gmail.com
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About