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

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

Thread Previous | Thread Next
From:
demerphq
Date:
May 5, 2017 07:44
Subject:
Re: [perl #128420] Changes in regex recursion in 5.24
Message ID:
CANgJU+V54fcM62EC2EZpb5uVu9Q9C1cY+0U51RbiGsgobZh7bA@mail.gmail.com
On 4 May 2017 23:41, "Craig A. Berry" <craig.a.berry@gmail.com> wrote:

On Wed, May 3, 2017 at 4:21 AM, demerphq <demerphq@gmail.com> wrote:
> [using * to mark my comments since apparently gmail html to text is
> broken for quoting]
> On 3 May 2017 at 10:19, Steve Hay <steve.m.hay@googlemail.com> wrote:


>> 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.

I think what's missing in this discussion is the degree to which the
base.pm business has completely gummed up the works of the maint
releases and that's really what got in your way.  Not saying that it
could be otherwise, but it has meant a very long code freeze in maint
which as far as I can remember has never happened before.  In any
normal year I don't think there would have been a problem applying
what you did to maint. If it were missing a vote we could have
scrounged another vote more easily than reverting.  Or agreed that
neither of the other two people on the planet qualified to review your
work on the regex engine was available to vote  Subject, of course, to
Steve's decision on a case-by-case basis, which would probably come
with a reminder about any parts of the maint policy that had been
overlooked.


Thanks for saying this.

All of which is to say, heavy-duty automation that enforces the maint
policy in a rigid way and is hard to turn on and off seems like
overkill to me.  Even with the many-month-long code freeze what
happened to you is unique as far as I know, and if we let such lengthy
freezes become the norm we've got bigger problems.


When I was in high school I did a short course in a sheet metal and machine
shop. During that course I got to use all sorts of crazy tools like
machines that could fold sheet metal like it was paper, or cutting devices
that could take your finger off before you even felt the pain. It taught me
a powerful respect for technical safety measures which has stuck with me
ever since.  So I personally don't see requiring vote lines in maint commit
message as a huge burden.

Having said that you have a point about not making policy from a black Swan
event.

We can ruminate on this for a bit and revisit it the next time someone
makes the same mistakes I did.

Cheers
Yves

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About