Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106222
MIME-Version: 1.0
References: <2311901d53767$1c5aa780$550ff680$@gmail.com> <CAJHtznx7u4wKDEjjARCtNd9o-HxCDzd_qERC0Js480sJ+Z9q4A@mail.gmail.com>
 <CAFPFaMLcMkD9j6km0kSP6O8zgQOO0ZggDxGHgLzrq2wTHMqMfg@mail.gmail.com> <CAJHtznzFkBaTYPx2XXLpvpHxExRarqmi9_i4NxBCK4UeugqUyw@mail.gmail.com>
In-Reply-To: <CAJHtznzFkBaTYPx2XXLpvpHxExRarqmi9_i4NxBCK4UeugqUyw@mail.gmail.com>
Date: Tue, 16 Jul 2019 18:06:40 +0200
Message-ID: <CAFPFaMLX=FarSTUM0tusumJSnjQE+V5gea=PmCM=5DF28DPgJw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c77fc9058dce90c9"
Subject: Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
From: george.banyard@gmail.com ("G. P. B.")

--000000000000c77fc9058dce90c9
Content-Type: text/plain; charset="UTF-8"

On Tue, 16 Jul 2019 at 17:00, Zeev Suraski <zeev@php.net> wrote:

> On Tue, Jul 16, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote:
>
>> The RFC process establishes a consensus when 2/3 of the voters agree,
>> which is currently the case.
>>
>
> As the author of that RFC, I can tell you with complete confidence that
> deprecations were not in the intended scope of that process.  It's quite
> evident from the language of the Voting RFC itself:
>
> "Given that changes to languages (as opposed to changes to apps or even
> frameworks) are for the most part irreversible - the purpose of the vote is
> to ensure that there's strong support for the proposed feature."
>
> If the bar to remove a feature is identical to introducing it - it's
> hardly irreversible.  The current behavior was never ever intended.  It
> wasn't even supposed to be used for deprecations - but for new features.
>

It seems this mention has been removed after the amendment from the
"Abolish Narrow Margin" RFC, and I'm also seeing that there hasn't been any
amendment made to the document after the "Abolish Short Votes" RFC passed".

I personally don't see the problem of having deprecation with the same
threshold as feature for voting, which is only mandatory since the Narrow
Margin RFC came into effect,  but this is only my opinion.
If you feel that strong about correcting this issue you could make an RFC
to amend the Voting RFC/Process, like Joe did (twice), to add a special
case for feature deprecation. And no I don't think the voting process need
a complete revamp.

Also, I just want to point out that, IMHO, the main reason for the high
amount of deprecations for PHP 7.4 is that it is the last minor version
before the next major. And who know how long it is going to take to have
the next major (supposedly 5 years) which is a long time in tech.


> An argument could be made that this isn't a large enough consensus -
>> something I don't agree with - however, at the time of writing this, all
>> the deprecations even pass a 3/4 consensus [4].
>>
>
> I think there are at least two issues that in a healthy environment would
> be needed:
>
> - A clear, tangible benefit to the deprecation.  Having another way of
> doing something certainly does not constitute a clear, tangible benefit to
> removing a feature.  This should be a pre-requisite for a deprecation.  In
> the past it was an obvious, implicit requirement - but that's from the days
> where we weren't as 'litigative', so it may make sense to explicitly point
> it out for the future.
>

This ties in to the point above about making an amendment to the Voting
process.


> - A much stronger consensus, that prevents the tyranny of the majority in
> such cases.  Whether it should be 100% or 95% - but it certainly shouldn't
> be 2/3 or even 3/4 - and should put into affect the notion that 'changes to
> the language are for the most part irreversible' - which was a fundamental
> tenet of the Voting RFC.
>
>  Zeev
>

These thresholds are, in my mind, pure insanity.
Let's run some numbers on how little people do you need to make a vote fail
with 95% (because 100% is always 1):
10 voters: 1 person (need 9.5 voters in favour),
15 voters: 1 person (need 14.25 voters in favour) ,
20 voters: 2 people (need 19 voters in favour) ,
25 voters: 2 people (need 23.75 voters in favour) ,
30 voters: 2 people (need 28.5 voters in favour, which is usually how many
people vote for "normal" RFC from what I see
35 voters: 2 people (need 33.25 voters in favour)
40 voters: 3 people (need 38 voters in favour)  about the number of people
currently voting on the PHP 7.4 deprecations RFC
45 voters: 3 people (need 42.75 voters in favour)
50 voters: 3 people (need 47.5 voters in favour)
55 voters: 3 people (need 52.25 voters in favour)  high profile RFCs
60 voters: 4 people (need 57 voters in favour)
65 voters: 4 people (need 61.75 voters in favour)
70 voters: 4 people (need 66.5 voters in favour) Typed property V2 RFC
(super high profile RFC)
75 voters: 4 people (need 71.25 voters in favour)
80 voters: 5 people (need 76 voters in favour)

This is madness: to make a vote fail you just need to find, with current
voting turnout, 2 other people to make a vote fail.
Sure it is possible for a tyranny of the majority but with these threshold
there is also clearly a tyranny of a minority because 56 voters in favour
and 3 against is IMHO a clear statement of consensus but would fail with a
95% majority.
And I don't think a 90% threshold is that much better. I think the highest
threshold I would possibly go with high discomfort is 80% (4/5).

I know that you're aren't necessarily keen on having so many people able to
vote, which is the opposite of what I believe as I think the more people
vote the better and more reflective of a vote we get.
That's why we are always going to end in disagreement about these things
IMO as we have opposite philosophies.

Side note: I replied to you resending this email is to let you know that at
least *someone* has read it -even before the resend - however I don't think
I'm the only one who's read it and didn't reply.

Best regards

George P. Banyard

--000000000000c77fc9058dce90c9--