Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125939
Date: Mon, 11 Nov 2024 01:14:54 -0600
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Message-ID: <1265782C-6018-40B9-84FD-0F22BF4DEECE@getmailspring.com>
In-Reply-To: <2bdad6e0-e5e0-48a6-bbd3-b938804287ca@app.fastmail.com>
References: <2bdad6e0-e5e0-48a6-bbd3-b938804287ca@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Policy on third party code
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="6731aeee_74b0dc51_2c98"
From: john@coggeshall.org (John Coggeshall)

--6731aeee_74b0dc51_2c98
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline



On Nov 11 2024, at 12:03 am, Larry Garfield <larry@garfieldtech.com> wrote:
>
> First off, the obligatory "it was open for discussion for a month, and now you mention this?"

I apologize for that, wasn't intentional. Unfortunately a whole pile of personal matters landed on my head between ... let's say October and November 6th that kept me from focusing on internals. As might be expected, the vote refocused my attention.
I think this is worth discussing a bit more below,...
TL;DR; I will at a minimum abstain from voting on this rather than vote "no" as my intent isn't to derail progress here.
> For using, yes, full frameworks are not allowed for the reasons stated. Components are fine, though, and if someone wanted to RFC an exception for Symfony-based bugs.php.net, they can try. That's more permissive than the current policy.
> For documentation... it's no change from the current status quo. If your concern is "zOMG, why can't we just tell people in the docs to use Symfony?", it's because someone else will immediately respond with "zOMG, why can't we just tell people to use Laravel instead?", and in a year or so someone will probably say "zOMG why can't we just tell people to use Tempest?" And then we'd have to argue if CodeIgnighter is something we want to even acknowledge exists. Full frameworks are a very, very active market, and I *agree* that we should try to avoid putting our thumb on the scales more than is necessary. Though again, there's an RFC process for exceptions.

Tangent, but FWIW I think this is something the PHP Foundation could help take on a bit, by creating a certification process a given framework can participate in. Any framework could apply, and all would be measured by the same reasonable standards.. then at least the PHP project could say "these frameworks have met this certification bar" which would be very helpful to people evaluating PHP as an option. I would gladly participate in drafting a rubric for community review if there was interest in that.
> So really, contrary to what you're saying, this RFC improves precisely the situation you're talking about in every way. Perhaps not as much as you would like, but it still moves the needle closer to it. I really don't have the stomach at the moment for litigating the "should we just go ahead and endorse some framework" question (I'm on team-no anyway), so I deliberately avoided that question when the main focus is to, as stated, let us mention Composer, PHPUnit, and other staples that have nowhere near the healthy competition that frameworks have.
As I eluded to above, I am certainly not suggesting we endorse a single framework. I guess at the end of the day I've got a number of issues with the specifics of the language around how decisions are made in this doc, but I will concede that at least there is a document here that can be refined which is indeed a step forward. If you're interested some the concerns I have are (I'm focused on the maintainer bits below but I think they also largely apply to the marketing criteria as well):
I don't think the "version 1.0" requirement is a good one, only because I strongly suspect it wouldn't take me very long to find a very reasonable library that for whatever reason is 0.8 or something... so now it can't be used, unless there is an RFC?
I don't understand what the point of the "Explicitly approved" list is, if the point is any and all libraries which meet the acceptance criteria can be used without asking for permission then they are by default approved, right?

Phrases like the library is a "de facto standard" is a really arbitrary, subjective criteria, ripe for misinterpretation or conflicting interpretation. As language it makes sense for the far edge cases and not much else IMO.

I'm not suggesting that these alternatives be adopted right now... but off the top of my head I would offer these suggestions:

The library should be focused on a specific need and provides clear, specific functionality needed by the PHP maintainers that would otherwise be unreasonable to implement and maintain themselves.
The library should have an active developer community of at least 2 developers, and the library should have an currently active development history of at least 1 year.

The library is provided under an Approved License

On the marketing side I think we've got a long way to go, but that can be a discussion for later.. for now I'll just say that I have a lot of the same issues as the maintainer side regarding versioning / subjectiveness, etc. In my mind the marketing guidelines are way more important to the project than the maintainer ones: We can always resolve conflicts regarding this stuff and maintainers internally, but if we miss opportunities to tell potential users how PHP can solve their problem effectively we may never see them again.

Anyway, like I said I'll abstain as my intention isn't to derail progress but I think this needs a lot more work as a set of guidelines. I'd be happy to help out with a second stab that if there is interest -- probably best off-list for a first draft?
Coogle

--6731aeee_74b0dc51_2c98
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Nov 11 2024, at=
 12:03 am, Larry Garfield &lt;larry=40garfieldtech.com&gt; wrote:</div><b=
lockquote><div><br><div>=46irst off, the obligatory =22it was open for di=
scussion for a month, and now you mention this=3F=22</div></div></blockqu=
ote><div><br><div>I apologize for that, wasn't intentional. Unfortunately=
 a whole pile of personal matters landed on my head between ... let's say=
 October and November 6th that kept me from focusing on internals. As mig=
ht be expected, the vote refocused my attention.</div><br><div>I think th=
is is worth discussing a bit more below,...</div><br><div>TL;DR; I will a=
t a minimum abstain from voting on this rather than vote =22no=22 as my i=
ntent isn't to derail progress here.</div><br><blockquote>=46or using, ye=
s, full frameworks are not allowed for the reasons stated. Components are=
 fine, though, and if someone wanted to R=46C an exception for Symfony-ba=
sed bugs.php.net, they can try. That's more permissive than the current p=
olicy.</blockquote><blockquote></blockquote><blockquote>=46or documentati=
on... it's no change from the current status quo. If your concern is =22z=
OMG, why can't we just tell people in the docs to use Symfony=3F=22, it's=
 because someone else will immediately respond with =22zOMG, why can't we=
 just tell people to use Laravel instead=3F=22, and in a year or so someo=
ne will probably say =22zOMG why can't we just tell people to use Tempest=
=3F=22 And then we'd have to argue if CodeIgnighter is something we want =
to even acknowledge exists. =46ull frameworks are a very, very active mar=
ket, and I *agree* that we should try to avoid putting our thumb on the s=
cales more than is necessary. Though again, there's an R=46C process for =
exceptions.</blockquote><br><div>Tangent, but =46WIW I think this is some=
thing the PHP =46oundation could help take on a bit, by creating a certif=
ication process a given framework can participate in. Any framework could=
 apply, and all would be measured by the same reasonable standards..&nbsp=
; then at least the PHP project could say =22these frameworks have met th=
is certification bar=22 which would be very helpful to people evaluating =
PHP as an option. I would gladly participate in drafting a rubric for com=
munity review if there was interest in that.</div><br><blockquote>So real=
ly, contrary to what you're saying, this R=46C improves precisely the sit=
uation you're talking about in every way. Perhaps not as much as you woul=
d like, but it still moves the needle closer to it. I really don't have t=
he stomach at the moment for litigating the =22should we just go ahead an=
d endorse some framework=22 question (I'm on team-no anyway), so I delibe=
rately avoided that question when the main focus is to, as stated, let us=
 mention Composer, PHPUnit, and other staples that have nowhere near the =
healthy competition that frameworks have.</blockquote><br><div>As I elude=
d to above, I am certainly not suggesting we endorse a single framework. =
I guess at the end of the day I've got a number of issues with the specif=
ics of the language around how decisions are made in this doc, but I will=
 concede that at least there is a document here that can be refined which=
 is indeed a step forward. If you're interested some the concerns I have =
are (I'm focused on the maintainer bits below but I think they also large=
ly apply to the marketing criteria as well):</div><br><ul><li><div>I don'=
t think the =22version 1.0=22 requirement is a good one, only because I s=
trongly suspect it wouldn't take me very long to find a very reasonable l=
ibrary that for whatever reason is 0.8 or something... so now it can't be=
 used, unless there is an R=46C=3F</div></li><li><div>I don't understand =
what the point of the =22Explicitly approved=22 list is, if the point is =
any and all libraries which meet the acceptance criteria can be used with=
out asking for permission then they are by default approved, right=3F</di=
v></li><li><div>Phrases like the library is a =22de facto standard=22 is =
a really arbitrary, subjective criteria, ripe for misinterpretation or co=
nflicting interpretation. As language it makes sense for the far edge cas=
es and not much else IMO.</div></li></ul><div>I'm not suggesting that the=
se alternatives be adopted right now... but off the top of my head I woul=
d offer these suggestions<span data-emoji-typing=3D=22true=22>:</span></d=
iv><br><ul><li><div>The library should be focused on a specific need and =
provides clear, specific functionality needed by the PHP maintainers that=
 would otherwise be unreasonable to implement and maintain themselves.</d=
iv></li><li><div>The library should have an active developer community of=
 at least 2 developers, and the library should have an currently active d=
evelopment history of at least 1 year. </div></li><li><div>The library is=
 provided under an Approved License</div></li></ul><div>On the marketing =
side I think we've got a long way to go, but that can be a discussion for=
 later.. for now I'll just say that I have a lot of the same issues as th=
e maintainer side regarding versioning / subjectiveness, etc. In my mind =
the marketing guidelines are way more important to the project than the m=
aintainer ones: We can always resolve conflicts regarding this stuff and =
maintainers internally, but if we miss opportunities to tell potential us=
ers how PHP can solve their problem effectively we may never see them aga=
in. </div><br><div>Anyway, like I said I'll abstain as my intention isn't=
 to derail progress but I think this needs a lot more work as a set of gu=
idelines. I'd be happy to help out with a second stab that if there is in=
terest -- probably best off-list for a first draft=3F</div><br><div>Coogl=
e</div><br></div>
--6731aeee_74b0dc51_2c98--