develooper Front page | perl.perl5.porters | Postings from May 2017

Re: [perl #128420] Changes in regex recursion in 5.24

Thread Previous | Thread Next
Steve Hay via perl5-porters
May 3, 2017 07:25
Re: [perl #128420] Changes in regex recursion in 5.24
Message ID:
On 3 May 2017 at 07:56, demerphq <> wrote:
> On 2 May 2017 at 22:49, Steve Hay <> wrote:
>> On 2 May 2017 at 18:38, demerphq <> wrote:
>>> On 2 May 2017 at 17:39, Dagfinn Ilmari Mannsåker <> wrote:
>>>> Dave Mitchell <> writes:
>>>>> On Mon, May 01, 2017 at 02:51:16AM +0100, Zefram wrote:
>>>>>> Jan Goyvaerts wrote:
>>>>>> >if ("aqzaqzaqz" =~ /(a(?R)z|q)*/) {
>>>>>> This has been fixed in blead.
>>>>> in particular, v5.25.0-36-gda7cf1c:
>>>>>     fix #128109 - do not move RExC_open_parens[0] in reginsert
>>>> That commit, and v5.25.1-196-gec5bd2262b, which adds a test for it,
>>>> cherry-pick cleanly to maint-5.24.  Seeing as it's a crasher and
>>>> regression from 5.22, it's a candidate for backporting according to
>>>> perlpolicy.
>>> I just pushed
>>> 78b60e1 Add tests for regex recursion
>>> 4539ae3 fix #128109 - do not move RExC_open_parens[0] in reginsert
>>> 5edefd5 fix #128085 - SIGSEGV in S_regmatch with S_study_chunk:
>>> Assertion "!frame" failed.
>>> to maint-5.24 -- I took the liberty of including 5edefd5 which was
>>> part of how I found out about #128109
>> I don't think this should have been done right now. maint-5.22 and
>> maint-5.24 are both still in code freeze pending the release of 5.22.4
>> and 5.24.2, which are intended only to contain the last @INC fixes
>> (and possibly some other security fixes, as per the previous releases
>> on those branches).
>> There are many, many other bug fixes (crashes and otherwise) that
>> could be backported, but haven't been yet. They were deliberately
>> being left for 5.24.3, once the last of the @INC fixes was out of the
>> way.
> Sigh. Honestly I give up. Our release process is broken. If it weren't
> for the fact that we are going to change these policies that I would
> insert a long rant here about how expecting our developers to keep
> track of all their patches, which branches they have and have not been
> merged and which they should be merged to in some distant point in
> time is not a good way manage things[1]. Just like distributing swords
> in lakes in the middle of the night not a sound way to form a
> government. :-)
> Anyway, bulk reverted in 9ecaf4dba7ccf61301f3a0ca342810f57060fbd6
> sorry for yet more revert turbulence.


> cheers,
> Yves
> [1] So here is the *short* rant: I know there are some on this list
> that one way or another do not find these types of things a burden.
> But processes should work for everybody, not just the meticulous and
> careful, and they should be robust to things like unexpected
> life-changes. This patch was written in a period when I was dealing
> with the death of my father and a very sick mother. Making sure the
> patch was backported at the right time so that it didn't violate a
> code freeze was simply not a priority for me, and as our release
> procedures and policies do not provide for any solution other than
> "remember yourself", no-one else was going to do it either. This to me
> says that the policies and procedures are broken by design.

I wasn't aware that the discussions over changes in branch management
were intended to cover maint releases too.

Regarding remembering that patches get backported, I think the
existing process is very simple, actually: Just add the patch to the
relevant voting file in the maint-votes branch and the maint release
manager will pick it up at the approrpiate point in time. That's the
whole point of having a maint release manager isn't it? -- so that
individual developers don't have to remember all these things
themselves. If ever a patch is non-trivial to backport then I will
seek assistance when I come to cherry-pick it, which is something that
I've done on several occasions in the past.

Also, patches are supposed to get three votes before being backported
-- something else that I didn't see happen on this occasion. Again,
the voting file takes care of that perfectly simply.

It's not obvious to me that this process needs to change since it
doesn't suffer from the "blockage" issue that blead has during a long
code freeze: There is no active development being done on maint
branches anyway (virtually by definition).

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