Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125734
Precedence: bulk
MIME-Version: 1.0
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
In-Reply-To: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
Date: Wed, 2 Oct 2024 16:17:14 -0300
Message-ID: <CADK1yXJMOSRY++NO3amtKip4wJPw-sVPcCJ0kAFU8HwYGPL38Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000048a3ae0623834bbc"
From: deleugyn@gmail.com (Deleu)

--00000000000048a3ae0623834bbc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 2, 2024 at 3:38=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> Since Jim's RFC proposal was criticized for being too vague, I hereby
> offer a somewhat more prescriptive policy proposal on using 3rd party
> code.  (With JIm's blessing.)  It's still more heuristics than rules, but=
 I
> think that's the right approach generally.  It also includes a voting
> mechanism to resolve edge cases when they come up.
>
> I'm sure we'll bikeshed it to death, but please keep an open mind about
> the concept in the first place.  PHP is more than just php-src, and that'=
s
> a good thing.  We need to catch up with that reality, while at the same
> time maintaining a reasonable neutrality about projects Internals doesn't
> manage directly.
>
> https://wiki.php.net/rfc/third-party-code
>
> *Puts on trusty flame-retardant suit*
>
> --
>   Larry Garfield
>   larry@garfieldtech.com
>

Good writeup. Although I was more of a fan of Jim's RFC which just targets
the main issue of bringing up in the mailing list that PHP cannot use X
because "endorsement", this is also a good alternative.

My only problem with it is in the "discussion" section:

Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel
> and Symfony are the market leaders in PHP frameworks, and WordPress
> dominates the CMS-oid market, it is a highly dynamic market, with literal=
ly
> dozens of players that have reasonable use. That makes listing them in th=
e
> documentation without =E2=80=9Cplaying favorites=E2=80=9D essentially imp=
ossible, and
> therefore none should be listed by name. They should also not be used
> directly to build any PHP tooling, again to avoid the appearance of
> endorsement. However, it may make sense to list several of them in passin=
g
> in marketing material, explicitly noting that they are just some among ma=
ny
> options.


It's 2024. If the foundation is hiring developers to improve the language
across the board (internals, docs, website, processes, marketing,
visibility, etc), it makes no sense that these folks (or any volunteer for
that matter) be explicitly and unquestionably denied the opportunity or
conversation to modernize the system which PHP tooling is built upon. Its
understandable for historical reasons that frameworks would come and go,
which is why a lot of PHP systems from the 2005-2015 era usually are built
with an in-house framework. But at least in my little personal context,
in-house frameworks have proved themselves to be a nightmare for PHP
software engineers at large. A lot of these market leaders open source
frameworks are sustainable companies with a decade of proven stability,
reliability and efficiency. The sole principle behind a framework is to
facilitate work and this discussion point makes a clear statement that work
cannot be facilitated.

I am very opinionated on what is the best tool to help build PHP tooling,
but it seems pretty clear to me that any framework would be better than no
framework because the alternative is that a framework will be built
in-house and nobody in the world will have prior experience with that one.

--=20
Marco Deleu

--00000000000048a3ae0623834bbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 2, 2024 at 3:38=E2=80=AFP=
M Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfie=
ldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Since Jim&#39;s RFC proposal was criticized for being too vague,=
 I hereby offer a somewhat more prescriptive policy proposal on using 3rd p=
arty code.=C2=A0 (With JIm&#39;s blessing.)=C2=A0 It&#39;s still more heuri=
stics than rules, but I think that&#39;s the right approach generally.=C2=
=A0 It also includes a voting mechanism to resolve edge cases when they com=
e up.<br>
<br>
I&#39;m sure we&#39;ll bikeshed it to death, but please keep an open mind a=
bout the concept in the first place.=C2=A0 PHP is more than just php-src, a=
nd that&#39;s a good thing.=C2=A0 We need to catch up with that reality, wh=
ile at the same time maintaining a reasonable neutrality about projects Int=
ernals doesn&#39;t manage directly.<br>
<br>
<a href=3D"https://wiki.php.net/rfc/third-party-code" rel=3D"noreferrer" ta=
rget=3D"_blank">https://wiki.php.net/rfc/third-party-code</a><br>
<br>
*Puts on trusty flame-retardant suit*<br>
<br>
-- <br>
=C2=A0 Larry Garfield<br>
=C2=A0 <a href=3D"mailto:larry@garfieldtech.com" target=3D"_blank">larry@ga=
rfieldtech.com</a><br>
</blockquote></div><div><br></div>Good writeup. Although I was more of a fa=
n of Jim&#39;s RFC which just targets the main issue of bringing up in the =
mailing list that PHP cannot use X because &quot;endorsement&quot;, this is=
 also a good alternative.<div><br></div><div>My only problem with it is in =
the &quot;discussion&quot; section:</div><div><br></div><div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Symfony, Laravel, Slim, Yii,WordPress, =
Drupal, TYPO3, etc. - While Laravel and Symfony are the market leaders in P=
HP frameworks, and WordPress dominates the CMS-oid market, it is a highly d=
ynamic market, with literally dozens of players that have reasonable use. T=
hat makes listing them in the documentation without =E2=80=9Cplaying favori=
tes=E2=80=9D essentially impossible, and therefore none should be listed by=
 name. They should also not be used directly to build any PHP tooling, agai=
n to avoid the appearance of endorsement. However, it may make sense to lis=
t several of them in passing in marketing material, explicitly noting that =
they are just some among many options.</blockquote><div><div><div><div><br>=
</div><div>It&#39;s 2024. If the foundation is hiring developers to improve=
 the language across the board (internals, docs, website, processes, market=
ing, visibility, etc), it makes no sense that these folks (or any volunteer=
 for that matter) be explicitly and unquestionably denied the opportunity o=
r conversation to modernize the system which PHP tooling is built upon. Its=
 understandable for historical reasons that frameworks would come and go, w=
hich is why a lot of PHP systems from the 2005-2015 era usually are built w=
ith an in-house framework. But at least in my little personal context, in-h=
ouse frameworks have proved themselves to be a nightmare for PHP software e=
ngineers at large. A lot of these market leaders open source frameworks are=
 sustainable companies with a decade of proven stability, reliability and e=
fficiency. The sole principle behind a framework is to facilitate work and =
this discussion point makes a clear statement that work cannot be facilitat=
ed.</div><div><br></div><div>I am very opinionated on what is the best tool=
 to help build PHP tooling, but it seems pretty clear to me that any framew=
ork would be better than no framework because the alternative is that a fra=
mework will be built in-house and nobody in the world will have prior exper=
ience with that one.</div><div><br></div><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><di=
v dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></d=
iv></div></div></div></div></div></div></div>

--00000000000048a3ae0623834bbc--