Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124834
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 08 Aug 2024 19:30:57 +0200
To: internals@lists.php.net
Message-ID: <3b4a84fe-300c-4613-bff4-0a75221031ac@app.fastmail.com>
In-Reply-To: <1f1cda9b-a159-4f92-90b0-2ca7a3cec262@heigl.org>
References: 
 <WAN6ETlWt7JfcVoyeYfY_F_eLE6WzQa87F7yi8SHISmyktMYx7YcA6oG5dis3gFeI36VBjSfjGw4AT6psFFDXEUNRrvKRRn4LxfdCxFBccw=@gpb.moe>
 <PH7PR16MB57811CD259E8AED311F017B7DEB82@PH7PR16MB5781.namprd16.prod.outlook.com>
 <0FA837CD-60C3-4F4C-9044-C44FB0AF5788@php.net>
 <32BE9C65-F955-44F0-B994-D588D851902E@heigl.org>
 <gnAbiicW1X5OlcgiqC7maaaaTnHsa_Qrfjy0oK04IgSdH-Hx59vqgxf-dDw_LCu24UitU8iHfoXkC79vFwgTLVGnSD5fmf_ZKQnpzfO7PKA=@gpb.moe>
 <1f1cda9b-a159-4f92-90b0-2ca7a3cec262@heigl.org>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a
 standard function
Content-Type: multipart/alternative;
 boundary=c41a343d377443fa900659875da3b399
From: rob@bottled.codes ("Rob Landers")

--c41a343d377443fa900659875da3b399
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Aug 8, 2024, at 16:10, Andreas Heigl wrote:
> Hey Gina, hey all
>=20
> Am 08.08.24 um 15:44 schrieb Gina P. Banyard:
> > On Wednesday, 7 August 2024 at 17:07, Andreas Heigl <andreas@heigl.o=
rg>=20
> > wrote:
> >> Stupid question maybe, but are we voting on the RFC or on the patch?
> >>
> >> If the patch does not match what.the RFC proposes, then the patch h=
as=20
> >> a problem. That should IMO though not affect voting on an RFC.
> >>
> >> Or am I.missimg something?
> >=20
> > In theory, it is the RFC idea.
> > In practice, a lot of the times it is the patch for complex features.
> >=20
> > However, it is still within the purview of core developers to veto t=
he=20
> > implementation of an RFC.
> > Which could be the case here rather than voting against the RFC outr=
ight.
>=20
> I have no problem that core developers veto a certain implementation o=
f=20
> an RFC. I actually expect them to do so.
>=20
> But the vote should IMO *always and exclusively* be based on the RFC.=20
> Not on the implementation. If the voting happens based on the=20
> implementation due to the complexity of the features that means that t=
he=20
> RFC is not wel written and needs to be improved. Or the implementation=20
> is problematic and needs to be vetoed by the core developers.
>=20
> Why do I think so? It becomes completely intransparent why an RFC was=20
> rejected when the voting happens based on a meager implementation as=20
> after some years no one will understand why a well written RFC was=20
> rejected. Especially when the discussion then also happens off-list an=
d=20
> on the actual code in github as that tears apart the information sourc=
es=20
> that need to be taken into consideration in hindsight.

I would expect any implementation done before the RFC is voted on to be =
entirely proof-of-concept, and not expected to be mergable as-is. Basica=
lly, a way to test out the new proposed RFC, but may have issues (such a=
s memory leaks or not all edge cases implemented). I, personally, wouldn=
=E2=80=99t expect an RFC to be declined based on the initial patch. That=
=E2=80=99s good information to add to the rfc how-to page.=20

=E2=80=94 Rob
--c41a343d377443fa900659875da3b399
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}=0Ap.MsoNormal,p.MsoNoSpacing{margin:0}</=
style></head><body><div><br></div><div><br></div><div>On Thu, Aug 8, 202=
4, at 16:10, Andreas Heigl wrote:<br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div>Hey Gina, hey all<br></div><div><br></div><div>Am 0=
8.08.24 um 15:44 schrieb Gina P. Banyard:<br></div><div>&gt; On Wednesda=
y, 7 August 2024 at 17:07, Andreas Heigl &lt;<a href=3D"mailto:andreas@h=
eigl.org">andreas@heigl.org</a>&gt;&nbsp;<br></div><div>&gt; wrote:<br><=
/div><div>&gt;&gt; Stupid question maybe, but are we voting on the RFC o=
r on the patch?<br></div><div>&gt;&gt;<br></div><div>&gt;&gt; If the pat=
ch does not match what.the RFC proposes, then the patch has&nbsp;<br></d=
iv><div>&gt;&gt; a problem. That should IMO though not affect voting on =
an RFC.<br></div><div>&gt;&gt;<br></div><div>&gt;&gt; Or am I.missimg so=
mething?<br></div><div>&gt;&nbsp;<br></div><div>&gt; In theory, it is th=
e RFC idea.<br></div><div>&gt; In practice, a lot of the times it is the=
 patch for complex features.<br></div><div>&gt;&nbsp;<br></div><div>&gt;=
 However, it is still within the purview of core developers to veto the&=
nbsp;<br></div><div>&gt; implementation of an RFC.<br></div><div>&gt; Wh=
ich could be the case here rather than voting against the RFC outright.<=
br></div><div><br></div><div>I have no problem that core developers veto=
 a certain implementation of&nbsp;<br></div><div>an RFC. I actually expe=
ct them to do so.<br></div><div><br></div><div>But the vote should IMO *=
always and exclusively* be based on the RFC.&nbsp;<br></div><div>Not on =
the implementation. If the voting happens based on the&nbsp;<br></div><d=
iv>implementation due to the complexity of the features that means that =
the&nbsp;<br></div><div>RFC is not wel written and needs to be improved.=
 Or the implementation&nbsp;<br></div><div>is problematic and needs to b=
e vetoed by the core developers.<br></div><div><br></div><div>Why do I t=
hink so? It becomes completely intransparent why an RFC was&nbsp;<br></d=
iv><div>rejected when the voting happens based on a meager implementatio=
n as&nbsp;<br></div><div>after some years no one will understand why a w=
ell written RFC was&nbsp;<br></div><div>rejected. Especially when the di=
scussion then also happens off-list and&nbsp;<br></div><div>on the actua=
l code in github as that tears apart the information sources&nbsp;<br></=
div><div>that need to be taken into consideration in hindsight.<br></div=
></blockquote><div><br></div><div>I would expect any implementation done=
 before the RFC is voted on to be entirely proof-of-concept, and not exp=
ected to be mergable as-is. Basically, a way to test out the new propose=
d RFC, but may have issues (such as memory leaks or not all edge cases i=
mplemented). I, personally, wouldn=E2=80=99t expect an RFC to be decline=
d based on the initial patch. That=E2=80=99s good information to add to =
the rfc how-to page.&nbsp;<br></div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob<br></div></body></html>
--c41a343d377443fa900659875da3b399--