Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106221 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30226 invoked from network); 16 Jul 2019 17:39:19 -0000 Received: from unknown (HELO tbjjbihbhebb.turbo-smtp.net) (199.187.174.11) by pb1.pair.com with SMTP; 16 Jul 2019 17:39:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.net; s=turbo-smtp; x=1563894045; h=DomainKey-Signature:Received: Received:MIME-Version:References:In-Reply-To:From:Date: Message-ID:Subject:To:Cc:Content-Type; bh=i+xXp8UtOAWyXaQqCT+lmN y63t0Pj+imHjA17A+l5eQ=; b=Va5WuHqHyIt3HzxI6KTwa2JfNugW4Vm24DxP8g PiCAEmyNOjMHo/KScRXrR0/9NwQrObRkWpBnabapexug/QUEzMn2nTQzwHEiXchl GUWFaHl029ypsyFxHsPuSaaAv2ZtpuaDkCuc3ABgSCRS2KkObjm4dGzr1V6tqGZ0 lbh2o= 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=l6w8tA9/jMoOPjodkLrR4Q8iNqsoB7x5JGsiGz4/SGpXES1EHchsc+jxiPMyt1 Y3S2sn1uWCM+cam0WF4CObNBbMWaALNH0cvV9Tscavj2gbKBPZreIoW+DdHxu0Fc s3x32yaf+Dfk7yDnYTjKL717Ud4FHliY8QmnVLGvRkIR4=; Received: (qmail 3383 invoked from network); 16 Jul 2019 15:00:44 -0000 Received: X-TurboSMTP-Tracking: 5163744472 X-Gm-Message-State: APjAAAWpPoyK7kv2fIRTet57FNKsMDRd1PTk6PlfexTSeA99dk7rZoLJ EukZW4cP8cPn/OMsW3q+DaCd6dXYJwlLnRuFw1M= X-Google-Smtp-Source: APXvYqx8ZiLu4LNg1zvFFhRMFdMT3ZpoFQ58I25IAh0Hn460nJtazci00Ze1Ej5sYRN2if6EiX7N+DkoIkP/OTKvXO8= X-Received: by 2002:a37:ad0f:: with SMTP id f15mr21485573qkm.68.1563289244067; Tue, 16 Jul 2019 08:00:44 -0700 (PDT) MIME-Version: 1.0 References: <2311901d53767$1c5aa780$550ff680$@gmail.com> In-Reply-To: Date: Tue, 16 Jul 2019 08:00:34 -0700 X-Gmail-Original-Message-Id: Message-ID: To: "G. P. B." Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000012eda2058dcda406" Subject: Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposed deprecations From: zeev@php.net (Zeev Suraski) --00000000000012eda2058dcda406 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2019 at 7:34 AM G. P. B. wrote: > On Tue, 16 Jul 2019 at 16:18, Zeev Suraski 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=C5=8Dns=C4= =93nsus* (=E2=80=9Cagreement, > accordance, unanimity=E2=80=9D) [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 --00000000000012eda2058dcda406--