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

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

Thread Previous | Thread Next
May 3, 2017 09:22
Re: [perl #128420] Changes in regex recursion in 5.24
Message ID:
[using * to mark my comments since apparently gmail html to text is
broken for quoting]
On 3 May 2017 at 10: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:
> 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.

* Ok, cool.

>> Also this maint-votes branch is pretty clunky. Why don't we just put a
>> file in blead? Then when you commit your patch you can do a follow up
>> patch to the file. We can exclude the file from the build process when
>> we do a release.
> I think this may have been discussed at the time the voting files were
> introduced, and there were some objections to having a file in blead
> because the votes being cast would then cause noise on the blead
> commit history.

* I see. Hrm. Thinking about it more if there was a tool that managed
it then it doesnt matter where it lives, and having the separate
branch is at least "fair" in that it is as easy, or hard to use,
regardless what your workflow is.

* I guess I have to write a tool. :-)

>> Anyway, if there is a file I can edit for these things then obviously
>> some of what I complained about has been addressed already.
>>> 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.
>> I was under the impression that there were, at least for two of the
>> three patches. For the latter I interpreted the approval for the other
>> a bit loosely and included it too, as they were all part of the same
>> meta-bug, if not specific bug-report.
> Sorry if I missed that. This is why having a file *somewhere* to keep
> track of the votes is definitely a good idea (IMO).

* Yes. The issues of votes requires somewhere to store and track them.

>>> 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).
>> No. I withdraw that. Albeit clunkier than I would like there is a
>> procedure to fire-and-forget, so the problem I complained about is
>> solved and I just didn't know it fully. I apologise for the noise, and
>> for not getting with the program quicker.
>> On the other hand, I then think we should put push blocks on these
>> branches and lock them down to the person who is doing the branch
>> management. I was just trying to "take care of business" without
>> realizing I was breaking the rules. IMO technical provisions to
>> prevent that kind of thing are a good idea.
> I think I would welcome the idea of push blocks (on the proposed blead
> release branch too) during code freeze because that's when it becomes
> most important to stop accidental commits, but I'm not sure they'd be
> necessary the rest of the time. Other committers have pushed to maint
> branches in the past. As long as it's well ahead of a release and
> follows the voting rules then I have no problem with that (it saves me
> a bit of work!). Would it be easy for the branch manager to add/remove
> these push blocks, or is it a more complicated thing to do that (e.g.)
> Dennis would have to do, and once it's done it's done?

* this is all me here

We could do that, but it would require some finagling. Perhaps better
would be to require a signed-off-by signature in the commit message.
Maybe something as simple as each commit requires at least three lines
of the form

vote: demerphq
vote: Steve Hay
vote: Dave Mitchell

then the push hook can validate that, and if it is missing give a
suitable message about how to mange all of this. If we have tools to
manage the vote branch we could even automate this process.

(IIRC There is a more formal git concept of signed-off-by but i dont
know all the details or how suitable it would be for us, I will dig
and see, although if someone knows feel free to educate us.)


perl -Mre=debug -e "/just|another|perl|hacker/"

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