Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107460
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DC2AC0D6-21EB-4D48-953F-CAE003C85FFF"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-ID: <67911D3D-CBC1-4847-9F4B-3C895EF84741@newclarity.net>
Date: Wed, 9 Oct 2019 17:16:22 -0400
Cc: PHP internals <internals@lists.php.net>
To: Lynn <kjarli@gmail.com>
Subject: Constraints and userland@
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_DC2AC0D6-21EB-4D48-953F-CAE003C85FFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 9, 2019, at 4:25 AM, Lynn <kjarli@gmail.com> wrote:
> There is no middle ground in an RFC that proposes the deprecation at =
this level of specifics. You either deprecate it, or you don't. The only =
middle ground you can reach, is that you give it a vote to see if it =
should indeed be deprecated. Perhaps I'm looking at it from a wrong =
perspective, it looks very binary to me (see next answer for why).=20

I will address the question of perspective below.

> The idea behind a deprecation is that you are discouraging its use and =
plan to remove it at a later stage. To me it makes no sense to deprecate =
something but never remove it, might as well not deprecate it at that =
point. Either we accept it's in the language and keep it, or we remove =
it at some point, which ideally gets a deprecation first to ease =
migrations.


There is not logical/logistical/technical reason why we cannot deprecate =
w/o a plan to remove. The only reason is that you and maybe others have =
established the constraint in your mind(s) that it is a requirement. And =
that is unfortunate, because there is absolutely nothing that would stop =
us from deprecating something with no current plan to remove.

But I am not challenging you.  People do this all the time in areas they =
care about. They establish constraints that only exist in their mind. I =
could give multiple example of where that happens in governmental =
politics, but I won't for fear of offending someone who has set =
constraints in their mind about any given example topic.

Instead I am asking you to be willing to find a workable solution and =
ask yourself this: Is this constraint which only exists in your attitude =
towards to topic really so important that we cannot consider revisiting =
it, especially if it will allow the PHP team to signal users not to use =
a disliked feature but also ensure that no userland code won't break? =
The tangible benefits here seem to be to outweigh the intangible =
constraints.

And please note, there is nothing that stops a future RFC from remove a =
feature at a future date assuming the community agrees that the BC =
concern for this feature is no longer the overriding concern.=20

But to force a constraint that does not actually exist feels like we are =
tying one hand behind our back prior to a fist-fight. Especially when =
making sure we have all available hands can potentially reduce the =
acrimony of these non-stop BC debates.


>  I agree. There are a lot of unhappy user-land voices about a lot of =
decisions made here. Sadly I don't see a way to give everyone a voice in =
this.


I do see a way to give userland a voice, and I have written up =
significant parts of a proposal for this, but it is far from complete.=20=


In a nutshell we could create a PHP userland advisory board to parallel =
internals, complete with it's own list named `userland@`.=20

As a straw man proposal there could be a set number of seats (~250?), =
divided up by how they are involved in PHP; corp developer, independent =
developer, framework vendor, hosting company, etc. They should =
participate as representatives of userland rather than as =
representatives of their own opinions. They would get to vote on things =
so we could gauge userland's interests, but their vote could only be =
used to veto an accepted RFC, and internals@ could override the veto if, =
say, 90% of internals@ members voted to do so. =20

We could also have requirements for these delegates to contribute in =
areas such as documentation, testing, and for those who are representing =
commercial interests, possibly even sponsorship funds (although this =
latter would require an entity to receive those funds and AFAIK that =
entity does not currently exist.)

And this could reduce traffic on the internals@ list as debates that =
affect userland could move to userland@ list.

The only thing left about this proposal is actually how to implement it, =
which is something that a working group of people could get together and =
create a proposal.  Assuming there are enough people that would embrace =
the idea to create said working group.

-Mike

--Apple-Mail=_DC2AC0D6-21EB-4D48-953F-CAE003C85FFF--