Front page | perl.perl5.porters |
Postings from April 2018
Re: 5.28.0 is pushed to May
From: Sawyer X
April 2, 2018 17:08
Re: 5.28.0 is pushed to May
Message ID: firstname.lastname@example.org
On 03/26/2018 02:39 PM, James E Keenan wrote:
> 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 <email@example.com>
>>>>>>> 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
>>>>>>> should have more time to be resolved, especially when the Perl
>>>>>>> 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.
This seems to me like an overtly unnecessary strictness on the
toolchain's time. If at any point, anyone in the toolchain would like to
work on blockers, they are free to do so. Why dictate to them how they
spend their time? And while you have some blockers this time that might
not be toolchain-related, this isn't always the case. This time we
reverted a fix that broke Module::Install but we would like to introduce
it again for 5.30. This is toolchain-related.