Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

This is only part of a thread. view whole thread
  106221
July 16, 2019 15:00 zeev@php.net (Zeev Suraski)
On Tue, Jul 16, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote:

> On Tue, 16 Jul 2019 at 16:18, Zeev Suraski <zeev@php.net> wrote: > Secondly the word you are looking for here is "unanimity"/"unanimous" as
> per the Cambridge dictionary [1]: > >> *If a group of people are unanimous, they all agree about one particular >> matter or vote the same way, and if a decision or judgment is unanimous, it >> is formed or supported by everyone in a group* > > > As consensus means, also from the Cambridge dictionary [2]: > >> *a generally accepted opinion or decision among a group of people* >> > > Now unanimity implies consensus however not having a unanimous vote does > not mean there is no consensus. > Moreover, even though "consensus" does come from the Latin *cōnsēnsus* (“agreement, > accordance, unanimity”) [3] it does not require unanimity IMHO. >
While there are different definitions for consensus - as you point out yourself, one of the definitions is certainly a synonym for uninamity - and that's how I personally found it commonly used throughout my life. Regardless, it certainly implies no strong disagreement from those in the minority - which is not the case here.
> 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. 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. - 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
  106222
July 16, 2019 16:06 george.banyard@gmail.com ("G. P. B.")
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. 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
  106226
July 17, 2019 14:33 zeev@php.net (Zeev Suraski)
On Tue, Jul 16, 2019 at 9:07 AM G. P. B. banyard@gmail.com> wrote:

> 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. 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,
True, I think it's an unfortunate side-effect of the somewhat hasty process that surrounded that amendment. It's completely clear from the background of the 'Abolish' RFC that the gripe was with the fact that there was differentiation between language features and non-language features, and not with the rationale for the need for a high bar. In the process, the rationale for having a strong majority (as opposed to having a regular 50%+1 majority) was entirely lost, which is unfortunate - but obviously does not change in any way the rationale itself.
> > 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. >
I agree - but I still fail to see that as a reason to deprecate things which are harmless (or that in other words - provide no tangible value upon removal). There are things on that list that would likely do no harm even if they existed in PHP 20.0. These thresholds are, in my mind, pure insanity.
> ... > 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). >
It's not madness at all. Deprecations need a strong, non-partisan case to be enacted. A lot of the deprecations on the current RFC simply do not have that. Others do, and you can easily tell the difference between them - consensus (or uninamity), vs. not. So it's clear that for good, valid deprecations - getting that 95% or even 100% uninamity is easy. The reality is that right now, the PHP project somehow became deprecation-oriented, and lost its long established guideline of bias for downwards compatibility. I'm absolutely positive that folks that voted in favour of deprecations have thought less about the implications of their votes compared to folks who voted against. It's simply easy to go with the flow, join the majority - without understanding the details I'd go as far as saying that had the other half of originally proposed deprecations stayed on the ballot - many of them would also clear - quite easily - the 2/3 bar - because of the pro-deprecation sentiment that currently exists on internals. We just have to be thankful that Nikita and Kalle were responsible to remove them ahead of time - I just wish they did the same thing with a few of the other ones. The solution may be to somehow 'bucketize' the deprecations, as security-related, maintenance-related or cleanliness-related (maybe there are other categories). Security related are probably fine with 2/3. Maintenance related (i.e. if there's no maintainer for a certain extension) may not even require a vote at all (but are probably fine with regular votes). It's the 'style' ones which are IMHO unacceptable for 2/3. In other words, without a tangible benefit - a deprecation proposal should either not be proposed at all, or should clear a virtually unanimous threshold to be enacted. Zeev
  106248
July 23, 2019 05:44 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> The reality is that right now, the PHP project somehow became > deprecation-oriented, and lost its long established guideline of bias for > downwards compatibility.
Hear, hear! I am positively astonished at so many RFCs trying to deprecate so many functions in PHP. Who does it help? Who did those functions hurt? I understand when we're deprecating something that does not work or has too many broken uses to use it right, etc. Sometimes we recognize we made a mistake and have to get rid of it (magic quotes!). But doing it just to "reduce the size of standard library" looks to me completely contrary to what PHP has always been about - going extra mile to make it easier for the user, even at the cost of redundancy. We're not one of those slick code golf languages where you can write witty one-liners that do something you won't remember next morning. We aim for people that actually do work with the language. Which means, we provide them with tools handy for various tasks, and we are very conservative in breaking their code - only as the last resort. So I must say I'm rather disappointed with the zeal people are voting for removing functions that hurt nobody. -- Stas Malyshev smalyshev@gmail.com
  106251
July 23, 2019 11:12 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Tue, 2019-07-16 at 08:00 -0700, Zeev Suraski wrote:
> > Now unanimity implies consensus however not having a unanimous vote > does > > not mean there is no consensus. > > Moreover, even though "consensus" does come from the Latin > *cōnsēnsus* (“agreement, > > accordance, unanimity”) [3] it does not require unanimity IMHO. > > > > While there are different definitions for consensus - as you point > out > yourself, one of the definitions is certainly a synonym for uninamity > - and > that's how I personally found it commonly used throughout my life. > Regardless, it certainly implies no strong disagreement from those in > the > minority - which is not the case here.
A good reading on consensus in technical discussions is this: https://tools.ietf.org/html/rfc7282 In my view there is a difference between a vote and consensus. In a vote I state "this is my preference" in a consensus I can say "it is not my preference, but I can support it" And I believe the key is to identify whether there are objections/vetos. Those have to be respected, as voting over volunteer contributors drives them away. Voting is good if there is no clear consensus or if one has to make a decision, left or right, and there's no clear consensus. Unanimity in a vote means that this is the preferred approach for everybody (among voters) On hebrev()/hebrevc(): I believe most contributors have no idea what it does and I for one have no need. It doesn't hurt me, though. As long as it works for the users I'd keep it since cost is low. If I'd support adding such a function in future is a different question. johannes
  106291
July 25, 2019 12:23 rowan.collins@gmail.com (Rowan Collins)
On Tue, 23 Jul 2019 at 12:12, Johannes Schlüter <johannes@schlueters.de>
wrote:

> A good reading on consensus in technical discussions is this: > https://tools.ietf.org/html/rfc7282
I just skimmed that document, and I think there's a lot we could learn from it, if we had the confidence to truly reform. You could pretty much replace "IETF" with "PHP" in this paragraph, and you'd have a summary of why we *shouldn't* rely on votes as much as we do:
> We don't vote in the IETF. In some ways, we can't vote: Since the > IETF is not a membership organization, it's nearly impossible to > figure out who would get a vote for any given question. We can't > know who the "members" of any given working group would be at any one > time, and we certainly can't know who all of the "members" of the > IETF would be: That's why we refer to "participants" in the IETF; the > IETF doesn't really have "members".
> On hebrev()/hebrevc(): I believe most contributors have no idea what it > does and I for one have no need. It doesn't hurt me, though. As long as > it works for the users I'd keep it since cost is low. If I'd support > adding such a function in future is a different question. >
I agree with everyone who has said removing a feature (and every "deprecation" is actually a proposal to remove something) should have a much higher bar than not adding it. I think there is also an extra requirement that removal (and therefore deprecation) should have, which many of these proposals *also* don't pass: what should people be using instead? To me, every deprecation note should be able to clearly say one of two things: - If you are using this feature, You Are Wrong. Don't do it, emulate it only as a short-term measure, work to remove it. - If you are using this feature, you should use this specific feature instead, because it is better in these ways. Take convert_cyr_string, for example. The RFC says "one of mb_convert_encoding(), iconv() or UConverter may be used for this purpose". There's a sleight of hand here - it sounds like we've offered the user an upgrade path, but we haven't actually said *how* to get the equivalent functionality. Why are there three options, all in different optional extensions? Will one of them be removed in a few years' time, leaving users to fix their code all over again? What options does each of these need to emulate the old function? Is it even possible, or will there be subtle differences that need testing? If the aim is to have a Right Way to do everything, we should be saying what that Right Way is. I picked this example in particular, because I'd actually love there to be better guidance on how to convert encodings, and I'd like to remove utf8_encode and utf8_decode, which I think cause far more damage by being so badly named. I haven't proposed it, because for the people who are using those functions correctly, there would need to be a clear replacement, and right now there isn't. Regards, -- Rowan Collins [IMSoP]