Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128295
Precedence: bulk
MIME-Version: 1.0
References: <ClHWqZ8xQp5NMLvOxMZ80CqdIr0QVhrCzJmDZyw0h7Z4CtK3DG8fW3dKbf4fu-WJRxvqBY9S_W29um3mHEaGJ9ee1epItOizujB3CpbNKfA=@gpb.moe>
 <EYKUX_e3wzCF2eOwU5beLQfcpz-0w4K1M5fjdITFJ0yND11XWgFm-bI_zh7hz8sNygSLrRLe8sTWz_vpcXPlq5o83R5QKfI_zxNzMu1w9eU=@gpb.moe>
 <3b303d303708b13a2de81dc07753da3a@bastelstu.be> <qHqe_cprXfMx8PAHwaMVUGmJWu94iC0thiRRjwn_hesackCjF6vbZXLie269X7_4AdHcs9By6j_gZX0L6E5aGjHctUCUESFPbC1sDLHd4EE=@gpb.moe>
In-Reply-To: <qHqe_cprXfMx8PAHwaMVUGmJWu94iC0thiRRjwn_hesackCjF6vbZXLie269X7_4AdHcs9By6j_gZX0L6E5aGjHctUCUESFPbC1sDLHd4EE=@gpb.moe>
Date: Tue, 29 Jul 2025 14:16:59 +0200
Message-ID: <CAEKnhAH7Kj5=9w1UFcxtkd0n8djYQ-J2je2PsXNxywsNSQe+mw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Warnings for PHP 8.5
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000397f29063b1063f5"
From: bukka@php.net (Jakub Zelenka)

--000000000000397f29063b1063f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 28, 2025 at 7:17=E2=80=AFPM Gina P. Banyard <internals@gpb.moe>=
 wrote:

> On Monday, 28 July 2025 at 16:22, Tim D=C3=BCsterhus <tim@bastelstu.be> w=
rote:
>
> > Am 2025-07-28 16:23, schrieb Gina P. Banyard:
> >
> > > As I am aware it is in bad taste to shove something new into such a
> > > proposal minutes before starting the vote,
> > > I'll postpone the vote for a few hours so that at least some people
> > > can see and raise objections.
> >
> >
> > For visibility: I object. See sibling email.
>
> Said sibling email:
>
> On Monday, 28 July 2025 at 15:31, Tim D=C3=BCsterhus <tim@bastelstu.be> w=
rote:
> > Am 2025-07-28 16:20, schrieb Gina P. Banyard:
> >
> > > I've added a whole new section that addresses this, as out of range
> > > casts are completely whack.
> > > See:
> > >
> https://wiki.php.net/rfc/warnings-php-8-5#casting_out_of_range_floats_to_=
int
> >
> >
> > This effectively is another =E2=80=9CPrimary Vote=E2=80=9D for an entir=
ely new proposal
> > and as such requires 2 weeks of discussion. If you want to vote on this
> > RFC for PHP 8.5, you'll need to drop that section again.
> >
> > Best regards
> > Tim D=C3=BCsterhus
>
> I am going to bring the RFC in its totality to a vote later today.
> You can consider this a new primary vote, vote no, and even argue for thi=
s
> part of the RFC to be rendered void regardless of the result.
> Or just incentivize people to vote no, so you don't even need to deal wit=
h
> this.
>
> Claude raised the edge case 2 days ago, and I found the extent of it to b=
e
> even larger than expected.
> I thought that it would be better to create a whole new section rather
> than twisting the existing "NAN" warning proposal to fit the new
> constraints,
> but apparently I should have done this instead and changed all instances
> of "NAN" to "non-representable floats".
>
> I find it increasingly frustrating that trying to make PHP not be
> completely insane is met with resistance at every turn,
> and I'm once more at the stage that I really should stop wasting my time
> and caring about PHP and do something better with my life.
> Using "process violations" to prevent PHP from being less shit when an
> additional edge case of a proposal is found, for IDK 5 additional years
> impacting countless developers, old and new, is something that I find
> infuriating.
> And I guess this truly showcases how broken and infuriating our RFC
> process can be, especially around feature freeze.
>
> Moreover, if we are going to do legalese, the only thing our policy actua=
l
> states are the following: [1]
>
> > There'd be a minimum of 2 weeks between when an RFC that touches the
> language is brought up on this list and when it's voted on is required.
> [...]
>
> > For procedural reasons, multiple RFCs may be combined into one, in whic=
h
> case there may be multiple primary votes.
> > Combining multiple RFCs into one does not allow turning a primary vote
> into a secondary vote.
>
> There is no mention of the content of an RFC needing to be "identical" fo=
r
> 2 weeks.
>

I guess this is a bit of a loop hole in the process but essentially I think
you have got right to add such last minute changes to the RFC and open vote
next day (or even next minute) if you want. The current policy doesn't
really consider those multi vote RFC's but technically it's still a single
RFC which is announced on internal just once and the date of announcement
on internals is what matters. If we should change those rules is really for
another discussion though.

Jakub

--000000000000397f29063b1063f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 28, 2025 at 7:17=E2=80=AFPM G=
ina P. Banyard &lt;internals@gpb.moe&gt; wrote:</div><div dir=3D"ltr"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On =
Monday, 28 July 2025 at 16:22, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim=
@bastelstu.be" target=3D"_blank">tim@bastelstu.be</a>&gt; wrote:<br>
<br>
&gt; Am 2025-07-28 16:23, schrieb Gina P. Banyard:<br>
&gt; <br>
&gt; &gt; As I am aware it is in bad taste to shove something new into such=
 a<br>
&gt; &gt; proposal minutes before starting the vote,<br>
&gt; &gt; I&#39;ll postpone the vote for a few hours so that at least some =
people<br>
&gt; &gt; can see and raise objections.<br>
&gt; <br>
&gt; <br>
&gt; For visibility: I object. See sibling email.<br>
<br>
Said sibling email:<br>
<br>
On Monday, 28 July 2025 at 15:31, Tim D=C3=BCsterhus &lt;<a href=3D"mailto:=
tim@bastelstu.be" target=3D"_blank">tim@bastelstu.be</a>&gt; wrote:<br>
&gt; Am 2025-07-28 16:20, schrieb Gina P. Banyard:<br>
&gt; <br>
&gt; &gt; I&#39;ve added a whole new section that addresses this, as out of=
 range<br>
&gt; &gt; casts are completely whack.<br>
&gt; &gt; See:<br>
&gt; &gt; <a href=3D"https://wiki.php.net/rfc/warnings-php-8-5#casting_out_=
of_range_floats_to_int" rel=3D"noreferrer" target=3D"_blank">https://wiki.p=
hp.net/rfc/warnings-php-8-5#casting_out_of_range_floats_to_int</a><br>
&gt; <br>
&gt; <br>
&gt; This effectively is another =E2=80=9CPrimary Vote=E2=80=9D for an enti=
rely new proposal<br>
&gt; and as such requires 2 weeks of discussion. If you want to vote on thi=
s<br>
&gt; RFC for PHP 8.5, you&#39;ll need to drop that section again.<br>
&gt; <br>
&gt; Best regards<br>
&gt; Tim D=C3=BCsterhus<br>
<br>
I am going to bring the RFC in its totality to a vote later today.<br>
You can consider this a new primary vote, vote no, and even argue for this =
part of the RFC to be rendered void regardless of the result.<br>
Or just incentivize people to vote no, so you don&#39;t even need to deal w=
ith this.<br>
<br>
Claude raised the edge case 2 days ago, and I found the extent of it to be =
even larger than expected.<br>
I thought that it would be better to create a whole new section rather than=
 twisting the existing &quot;NAN&quot; warning proposal to fit the new cons=
traints,<br>
but apparently I should have done this instead and changed all instances of=
 &quot;NAN&quot; to &quot;non-representable floats&quot;.<br>
<br>
I find it increasingly frustrating that trying to make PHP not be completel=
y insane is met with resistance at every turn,<br>
and I&#39;m once more at the stage that I really should stop wasting my tim=
e and caring about PHP and do something better with my life.<br>
Using &quot;process violations&quot; to prevent PHP from being less shit wh=
en an additional edge case of a proposal is found, for IDK 5 additional yea=
rs impacting countless developers, old and new, is something that I find in=
furiating.<br>
And I guess this truly showcases how broken and infuriating our RFC process=
 can be, especially around feature freeze.<br>
<br>
Moreover, if we are going to do legalese, the only thing our policy actual =
states are the following: [1]<br>
<br>
&gt; There&#39;d be a minimum of 2 weeks between when an RFC that touches t=
he language is brought up on this list and when it&#39;s voted on is requir=
ed. [...]<br>
<br>
&gt; For procedural reasons, multiple RFCs may be combined into one, in whi=
ch case there may be multiple primary votes.<br>
&gt; Combining multiple RFCs into one does not allow turning a primary vote=
 into a secondary vote.<br>
<br>
There is no mention of the content of an RFC needing to be &quot;identical&=
quot; for 2 weeks.<br></blockquote><div><br></div><div>I guess this is a bi=
t of a loop hole in the process but essentially I think you have got right =
to add such last minute changes to the RFC and open vote next day (or even =
next minute) if you want. The current policy doesn&#39;t really consider th=
ose multi vote RFC&#39;s but technically it&#39;s still a single RFC which =
is announced on internal just once and the date of announcement on internal=
s is what matters. If we should change those rules is really for another di=
scussion though.</div><div><br></div><div>Jakub</div></div></div>
</div>

--000000000000397f29063b1063f5--