Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106226
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=IeSuz2iZ4C4/+cG5Ffa+lxc+LvyFEBskHvvru6u/UR02o0RYsNC2eSooYyTyAs
	y+ckl78hQh1RxK4BRpAmYJOae1cYcGzQAXgUk2RRkcF2H3KiAtcPUqQBVedlWr8l
	xs9xbEMEG84sVopmeGhI5JrBk/eAuUwaYNOhleBezKzW0=;
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> <CAFPFaMLX=FarSTUM0tusumJSnjQE+V5gea=PmCM=5DF28DPgJw@mail.gmail.com>
In-Reply-To: <CAFPFaMLX=FarSTUM0tusumJSnjQE+V5gea=PmCM=5DF28DPgJw@mail.gmail.com>
Date: Wed, 17 Jul 2019 07:33:35 -0700
Message-ID: <CAJHtzny6SdfCc3bPLWj5ZAiD9sMYrF3hxMu33sM-_0cWmoX+fw@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076374d058de16193"
Subject: Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations
From: zeev@php.net (Zeev Suraski)

--00000000000076374d058de16193
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 16, 2019 at 9:07 AM G. P. B. <george.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. <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,


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

--00000000000076374d058de16193--