Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115770
MIME-Version: 1.0
References: <CAOWwgpn0ZKV1ZA5pErEjwQVXsHpyb9zoA1VT7DsHC0=SeVeXJg@mail.gmail.com>
 <CACwt+Je+t0p9eF+6Q3Urk7b4k6qPQtkRRqBg3P+tEb_t_W2H_g@mail.gmail.com>
 <72785D6F-6803-49BB-B575-01061699ABF4@gmail.com> <CAJW__o3yDUB1TU9sLmKfs3CHS2V660S3uyGDffEojzcwYFGKhw@mail.gmail.com>
 <448DAADA-C819-457F-ABBF-F942128B2830@gmail.com> <CADK1yXL6urFvFCy3zfcMiOD5So_wk4dMSEJSkS-O5JKD=QPqnw@mail.gmail.com>
 <CAOwTYAu_gA7Lre-xmzMV1Jny4r23ud2OFis7GSPd9Z8=Bh1QnQ@mail.gmail.com>
 <CAF+90c-C+qvmNg8tasL+QpT_-VW2_amXOR9LEXcY91qDYU22cQ@mail.gmail.com>
 <CAOwTYAskxE0MUta2dJKUW8pxfbH4BYinPYtbY5myWNbAOjfcZw@mail.gmail.com> <CAOWwgpnAhJ7-t_o429tN_+=JqRJDsvha0dvSxNEMyZVtcocCAw@mail.gmail.com>
In-Reply-To: <CAOWwgpnAhJ7-t_o429tN_+=JqRJDsvha0dvSxNEMyZVtcocCAw@mail.gmail.com>
Date: Mon, 23 Aug 2021 00:42:24 +0200
Message-ID: <CACwt+JcX9NQ7_xn4HVwnQ=g3sqJ4iitGyXumrjnq-JNtuz1j=g@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: Joe Watkins <krakjoe@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, Deleu <deleugyn@gmail.com>, 
	Tobias Nyholm <tobias.nyholm@gmail.com>, Kalle Sommer Nielsen <kalle@php.net>, 
	PHP Internals List <internals@lists.php.net>, Ben Ramsey <ben@benramsey.com>
Content-Type: multipart/alternative; boundary="000000000000eb8f6a05ca2d9d13"
Subject: Re: [PHP-DEV] [VOTE] Nullable intersection types
From: patrickallaert@php.net (Patrick ALLAERT)

--000000000000eb8f6a05ca2d9d13
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Nicolas,

Le jeu. 19 ao=C3=BBt 2021 =C3=A0 12:25, Nicolas Grekas <nicolas.grekas@gmai=
l.com> a
=C3=A9crit :

> What a mess! I feel so disappointed by the lack of clarity of the
> processes here.
>

You aren't alone and it is challenging to make that kind of decision. I
would have been more confident saying it's ok if the process and feature
freeze was clear about the fact that even syntax changes are allowed a
couple of days before a RC1 provided that it touches a new feature.


> The RFC was granted a "go" by a release manager, but suddenly, in the
> middle of the vote, another release manager raised an objection to this
> grant!?
>

I'm sorry for the timing and I was also not aware of it.


> This should have been discussed before between release managers.
>

Agreed! That would have been ideal.


> Also, this "go" is now apparently revoked based on the partial results of
> the vote. This is obviously interfering with the vote itself! I'm not
> blaming any individuals, but some processes should clarify how this is
> supposed to work. At least please coordinate together on such topics!  =
=F0=9F=99=8F
>

> The processes also lack clarity about what the feature freeze is supposed
> to mean. We're having a metadiscussion about whether this RFC can target
> 8.1 or not, and many ppl stated that they would vote against it not becau=
se
> they don't want nullability, but because they don't want it in 8.1, or
> because they feel it's too late for 8.1. I can't blame them for that, but
> what is "feature freeze" supposed to mean if we aren't allowed to discuss=
,
> alter, or even revert not-yet-released features?!?
>

I share with you the lack of clarity.

Commenting on the various aspects of feature freeze (personal pov):
- discuss: discussing shouldn't be prevented in any way, never.
- alter: that is the most touchy part as alteration might be about very
various levels: edge cases, implementation details, conceptual ones,
syntax,... In a feature freeze, I would only consider minor changes that
wouldn't have influenced the way people would have voted the RFC. That
would exclude any conceptual changes as well as syntax ones.
- revert: if there are evidence that something that has been voted "yes"
really brings unforeseen challenges and provided that a majority would
recognize something that has been accepted should better be reverted, I
think we must be open to revert the introduction of a new feature: better
not having a new (buggy?) feature than a solid one later.

In the case of your new RFC: I rather see it as another feature on top of a
new one that even requires syntax changes. It may prove that the original
one was not rock-solid enough but it may also be seen as an extension of it=
.


> This should be shielded by some consensus on what is allowed during the
> feature freeze. On my side: anything that is not yet released should be
> re-discussable until either beta or RC stage. If we choose to go with bet=
a,
> we should give more time between the start of the feature freeze and the
> first beta, precisely to fix what happened to this RFC, aka to give a
> window for the community (me here) to play with the soon-to-be features a=
nd
> give feedback.
>

Either extra time, or having a way to influence the schedule of the
releases.
For now, we work with a fixed schedule and don't know (at least: me) how
strict we must stick to it.

The fixed schedule of the releases is what makes me more comfortable with
the idea of reverting a new feature rather than extending the scope of one.


> Based on the partial results of the vote, we could conclude that the
> consensus is to 1. not allow nullability and 2. force bracket around
> (X&Y)|null. I can't read this as anything else than ppl voting not on the
> RFC, but on this metadiscussion about the feature freeze + some fear that
> we might put ourselves in a corner with the syntax.
>
> The RFC should be allowed to complete, it's gathering important data.
>>
>
> Because of what I just wrote about, I don't think we can rely on any data
> here. The discussion should be rebooted from scratch for me. Apparently, =
we
> need the full syntax for composite types to decide for the syntax for
> nullable intersection types. =C2=AF\_(=E3=83=84)_/=C2=AF
>

I also think that we can't rely on the data for the reason you mention even
if I intended to vote "no" on the feature, not on the targeted version of
PHP, I may be the exception there.


> Now, I don't know what to do. The vote started and is not looking good fo=
r
> the proposal. Some will say that I didn't want to see it fail if I withdr=
aw
> it. But honestly, with all those interferences, I'm not sure the conditio=
ns
> are met to have a fair vote.
>

I understand you Nicolas. Let me and the other RMs have a chat about that
so that we explore all the possible options


> Please advise (release managers mainly I suppose, since you're the only
> ones having some sort of official authority here).
>
> Nicolas
>

Cheers,
Patrick

--000000000000eb8f6a05ca2d9d13--