develooper Front page | perl.perl5.porters | Postings from March 2018

Re: 5.28.0 is pushed to May

Thread Previous | Thread Next
James E Keenan
March 26, 2018 11:39
Re: 5.28.0 is pushed to May
Message ID:
On 03/26/2018 03:47 AM, Sawyer X wrote:
> On 03/24/2018 12:48 AM, James E Keenan wrote:
>> On 03/23/2018 03:30 PM, Karl Williamson wrote:
>>> On 03/23/2018 01:13 PM, Sawyer X wrote:
>>>> On 23 March 2018 at 22:03, Neil Bowers <> wrote:
>>>>>> TL;DR: Due to a request from the Toolchain and upcoming maintenance
>>>>>> releases, we decided to push the release of 5.28.0 to May instead
>>>>>> of April.
>>>>>> […]
>>>>>> The Toolchain has raised a concern that BBCs (CPAN breakage blockers)
>>>>>> should have more time to be resolved, especially when the Perl
>>>>>> Toolchain
>>>>>> Summit (PTS) is happening in April.
>>>>> Would it be helpful for the Perl release schedule if, in general,
>>>>> we aimed to have the PTS in March, rather than April/May?
>>>> I have not heard myself the concerns about the May releases, so I
>>>> don't know how much of it a problem it is to move releases more
>>>> officially to May. If anyone has objections or concerns, let me know.
>>> I'm concerned that there isn't enough time after the PTS to
>>> incorporate whatever needs to be done in time for a May release
>> Speaking from the perspective of someone who is only peripherally
>> involved in Perl Toolchain activity* but who is much more involved in
>> Perl 5 Porters activity ...
>> I don't think the PTS participants should be focused on preparing for
>> an imminent Perl 5 production release.  They should be focusing on the
>> toolchain and its development over the next year or so.  Granted, part
>> of that toolchain ships with core, but most of it does not.  In any
>> event, if a PTS happens one month before a Perl 5 annual release, we
>> -- P5P -- should be deep into code freeze at that point, hence,
>> unaffected by whatever happens at PTS.
> This isn't the reason. The particular problem raised were with toolchain
> which will be affected by the Perl release. Think of a toolchain module
> (or a CPAN upstream river module) that is broken on blead. The extra
> time will help resolve it on CPAN before the release is out.

Okay, but in that case we should *already* be able to identify those 
modules which are broken in blead *and* which are considered part of the 
toolchain.  My own reading of the data (see 
suggests that while there are still *important* CPAN distributions in 
other-than-PASS condition, those are not toolchain distributions per see 
(Tim Bunce having updated Devel-NYTProf overnight).  Important 
distributions which as of 5.27.10 are in non-PASS status appear to fall 
into two categories:

* Distributions whose maintainers have not yet applied patches proposed 
in response to breakage by blead which we have deemed legitimate 
(including breakage in the previous dev cycle).

* Distributions that require external libraries, complex configuration 
and are difficult (for me, at least) to test in an automated testing 
environment (e.g., DBD::Pg and DBD::mysql).

My recollection of the reports coming out of previous toolchain 
summits/QA hackathons has been that they have not focused on distros in 
those two categories.  Is my recollection incorrect?

In short, I believe that it's P5P job to *repair* the current toolchain 
to the extent that P5P harms it.  It's PTS's job to improve and extend 
the toolchain.

>> I do favor a month separation between PTS and Perl 5 release, for the
>> same reason as I favor a month separation between Perl 5 release and
>> TPC::NA, namely, some people are heavily involved on each side of each
>> pair of events and they/we need time to breathe.
> That's a good point, Jim.

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