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
James E Keenan
February 27, 2023 14:29
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
On 2/27/23 08:46, Jeremy Hetzler wrote:
 > On Mon, Feb 27, 2023 at 7:47 AM demerphq <> wrote:
 >>>> That wasn't my point however, my point was it would be helpful if 
 >>>> could take the time to build perl against the latest commit in the 
 >>>> branch on github and then test it against their favourite modules. If
 >>>> anything doesn't build, file a patch with the author of the module 
and or
 >>>> maybe with us as an issue.
 >>> That's incredibly onerous.
 >> I'm sorry you feel that way.  It's what all the people who work hard 
to maintain perl do all the time.
 >>> Can't you just get the patched version(s)
 >>> of Perl into cpan-testers and get everything tested automatically by
 >>> the next morning, together with a nice page of idiot lights which show
 >>> Where Things Failed?
 >> IMO no. There are tens of thousands of modules on CPAN, and we can 
merge dozens of commits a day sometimes. It's a lot bigger of an 
undertaking than you seem to realize.
 >> On the other hand, pulling the latest code, and then using perlbrew 
to build it and install it locally and then using cpanm to install your 
favorite dependencies is not that difficult.
 > I wonder, is there any way to surface any of the existing
 > blead-breaks-CPAN information for module authors to use?

What we refer to as "blead-breaks-CPAN" (or "BBC") is in the first 
instance, just a subset of data generated by individual contributors to 
the CPANtesters projects.  If you are a CPAN author/maintainer and 
someone tests your distribution against *any* version of Perl, on *any* 
operating system, with *any* configuration of Perl, and your 
distribution fails to build or experiences test failures, then an email 
is generated to you and sent within 24 hours.  The breakage is also 
displayed on the web at (or which is searchable by CPAN distribution.

That report tells you, the distribution author/maintainer, and anyone 
else *what* broke but not *why* it broke or what must be done to get the 
distribution to build and test properly again.  Determining the 'why' 
and the 'what is to be done' is a process that must be done by humans 
and cannot be automated.

There are a number of people who, over what is now *decades* of 
CPANtesting work, have evolved their own procedures for periodically 
testing a large number of CPAN distributions against Perl's monthly 
development releases.  Most of what we refer to as "BBC failures" are 
really failures against the most recent monthly dev release.  We depend 
on those people, as well as individual CPAN maintainers whose code 
appears to have been broken by recent dev releases, to report BBC 
failures to our GitHub issues queue.  We periodically review these 
issues; I try to slap a "BBC" label on them in GitHub, which makes them 
selectable in the interface.  We try to triage these bug reports along 
these lines:

* Is the problem a clear, unambiguous mistake in Perl's development 
branch ("blead"), such that the onus is on Perl 5 Porters to correct, 
with no action needed on the part of the CPAN maintainer?

* Is the problem sub-optimal code in the CPAN distribution whose 
problems were there all along but only exposed via a change in Perl 
blead, such that the onus is on the CPAN maintainer to fix?  (If we have 
the time available, we -- P5P -- will try to prepare a patch for the 
CPAN maintainer's consideration, but this cannot be guaranteed.)

* Is it some combination of the first two bullet points, such that P5P 
and the CPAN maintainers must negotiate a solution?

 > @demerphq, it seems like you have some way of knowing which CPAN
 > modules are broken by blead. Where does that information come from?
 > What would be the easiest way to just blat it onto a webpage that
 > module authors could access?

As mentioned above, CPAN author/maintainers are notified of failures on 
CPANtesters by email.  Should those failures have occurred against 
recent dev releases, the maintainers should contact P5P immediately.  We 
try our best, but, as @demerphq noted, the size of CPAN means that even 
the automatable parts of the process have a formidable scope -- and the 
analytical parts of the process cannot be automated.

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