Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103939
MIME-Version: 1.0
References: <CAOwTYAsePeRLZZVK=QKftoOtug2_F=5bsti56z2mJfBXP0u4rw@mail.gmail.com>
 <DM6PR02MB5594D2DE0A166B13024E44B9AC910@DM6PR02MB5594.namprd02.prod.outlook.com>
 <CAF+90c84ukPn2AwGL5-8srOwO=8MhhgG7-BFGfw9t8oSZHb_2w@mail.gmail.com> <CAJHtzny4gBkfCS42SOup+GO-Nqd-xC-9S4k=JthFvBB134=Xzg@mail.gmail.com>
In-Reply-To: <CAJHtzny4gBkfCS42SOup+GO-Nqd-xC-9S4k=JthFvBB134=Xzg@mail.gmail.com>
Date: Thu, 31 Jan 2019 18:00:20 +0100
Message-ID: <CAF+90c_bmePEVY7pAJmrDn0YThc-XQi7CZZLmMRy1XYDvAtYfw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Zeev Suraski <zeev@zend.com>, Joe Watkins <krakjoe@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000376f1f0580c3f78f"
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000376f1f0580c3f78f
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 4:27 PM Zeev Suraski <zeev@php.net> wrote:

>
>
> On Thu, Jan 31, 2019 at 4:55 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> I agree with Joe here that we should handle the question of voting margins
>> separately. Your RFC is a much more comprehensive reform, which contains a
>> number of points that look highly controversial to me (such as the
>> eligible
>> voter changes). It may take a long time until we reach a satisfactory
>> consensus there.
>>
>> On the other hand, this RFC is very simple and at least to me a complete
>> no-brainer. I already use 2/3 majority for all my votes, because I very
>> strongly believe that changes to PHP need to be held to a much higher
>> standard than a simple majority. It is outright shameful that
>> functionality
>> can be added to PHP if 21 vote in favor and 20 against. That's not a
>> consensus, that's a complete disagreement.
>>
>> It's not necessary to decide all questions regarding the RFC process at
>> once. Voting threshold is a very self-contained issue and we can decide it
>> separately from other controversial changes.
>
>
> Well, I think there are several issues here.
>
> One - while the passing threshold is probably one of the most painful
> issues with the current Voting RFC, it's hardly the only one.  Given it's
> taken us many years to start tackling this, I think it's safe to say that
> as a rule, we lack the motivation to tackle these issues.  I think it's
> pretty clear that if we solve the threshold issue independently, it would
> likely be years before we tackle the other issues, if ever.
>
> Secondly - the threshold and voting eligibility are not, in any way,
> independent.  They're two fundamental aspects of the same topic - how votes
> take place.  A 2/3 majority out of a subset of ~200-300 people is very
> different from a 2/3 majority out of a potential group of several thousand
> people
>
> Thirdly - implementation issues - that the original Voting RFC did NOT
> intend to cover, later became covered by it by virtue of assumption.  I
> think that implementation issues (implementing the same functionality that
> we have right now in a better way) should not be subject to a vote, and
> moving the threshold to 2/3 makes the current situation even worse than it
> currently is, and should be for the most part up to the maintainers of the
> code.
>
> So no, I don't think we can simply 'abolish narrow margins' without
> thinking about the implications as well as tackling the other shortcomings
> of the 2011 Voting RFC.  With due respect, it reminds me of the hasty
> approach we took back then, and that wasn't good.
>
> Unless I'm missing something, we're currently in absolutely no hurry - we
> just released 7.3, we can spend as much time as needed (to a reason) on
> hashing out updated voting rules.  I'm speaking on behalf of myself, and
> maybe Dmitry thinks differently - but I'm certainly fine waiting with that
> RFC for several weeks or even a couple of months if needed.
>
> Zeev
>

Let me reply to the last point first, because I think that's really the
crux here: The issue is not that this RFC is very urgent per se, it's that
it has already been delayed numerous times and it is imperative that we
prevent that from happening again. Since this issue was first raised, a
number of RFCs have passed with narrow voting margins. Every time that
happens, I think "damn, why didn't we go through with the voting threshold
RFC?"

This RFC has been delayed for various reasons in the past -- those reasons
sounded good at the time, but the end effect is still the same: RFCs being
accepted with unreasonable margins. If we delay this again and it turns out
that your competing RFC stays in limbo for the next two years, or is simply
not accepted due to changes unrelated to voting margins, I would consider
that to be quite unfortunate.

If you have concerns with the details of the rules outlined in this RFC,
I'm sure that Joe is open to discussing them. But let's please make sure
that this particular question is resolved in a timely manner, which I think
requires it to be tackled separately from other issues.

Regarding your point about implementation issues: I'm not really sure I
understand it. Generally implementation issues are decided by a small group
of people (usually Dmitry, Bob and myself), often without even going
through the internals list. Of course very large changes (like say phpng)
should go through the RFC process simply because they affect many more
people (in particular also extension authors). Apart from that, I'm not
sure which other "implementation" RFCs you have in mind here.

Regards,
Nikita

PS: I think this thread went thoroughly off track and now mostly discusses
the FFI extension rather than this RFC ... Maybe that should be moved
elsewhere?

--000000000000376f1f0580c3f78f--