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

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

Thread Previous | Thread Next
Steve Hay via perl5-porters
July 20, 2017 13:13
Re: [perl #128420] Changes in regex recursion in 5.24
Message ID:
On 3 May 2017 at 09:19, Steve Hay <> wrote:
> On 3 May 2017 at 09:00, demerphq <> wrote:
>> On 3 May 2017 at 09:25, Steve Hay <> wrote:
>>> 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.
>>> Thanks.
>>>> 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.
>> I had no direct thoughts on this, but when i wrote that mail I was
>> thinking that they kinda flow together. However some of what you say
>> below makes me reconsider.
>>> 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.
>> Ok, I think I missed some of these details being announced. However I
>> see no mention of a maint-votes branch in the docs, at least not the
>> docs for 5.24.
> You're right - there is no mention of it in the docs (even in blead),
> which amazes me. We've been using this process for some time now, and
> documenting it after some trial period has evidently slipped through
> the cracks. Sorry about that. I will try to fix that, though perhaps
> it should wait until we've made any changes in light of your proposals
> below.

I've now documented the current process in commit

Hopefully this will avert similar confusion in the future. If not then
we may need to reconsider things.

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