Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125940
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 11 Nov 2024 02:38:08 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <65a90257-b9d1-4ff2-9d4c-b4c4b6c7d4b2@app.fastmail.com>
In-Reply-To: <1265782C-6018-40B9-84FD-0F22BF4DEECE@getmailspring.com>
References: <2bdad6e0-e5e0-48a6-bbd3-b938804287ca@app.fastmail.com>
 <1265782C-6018-40B9-84FD-0F22BF4DEECE@getmailspring.com>
Subject: Re: [PHP-DEV] [RFC][Vote] Policy on third party code
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Nov 11, 2024, at 1:14 AM, John Coggeshall wrote:
> On Nov 11 2024, at 12:03 am, Larry Garfield <larry@garfieldtech.com> w=
rote:
>>=20
>> First off, the obligatory "it was open for discussion for a month, an=
d now you mention this?"
>
> I apologize for that, wasn't intentional. Unfortunately a whole pile o=
f=20
> personal matters landed on my head between ... let's say October and=20
> November 6th that kept me from focusing on internals. As might be=20
> expected, the vote refocused my attention.

Quite...=20

> I think this is worth discussing a bit more below,...
>
> TL;DR; I will at a minimum abstain from voting on this rather than vot=
e=20
> "no" as my intent isn't to derail progress here.

Thank you.  I appreciate your openness here.

> As I eluded to above, I am certainly not suggesting we endorse a singl=
e=20
> framework. I guess at the end of the day I've got a number of issues=20
> with the specifics of the language around how decisions are made in=20
> this doc, but I will concede that at least there is a document here=20
> that can be refined which is indeed a step forward. If you're=20
> interested some the concerns I have are (I'm focused on the maintainer=20
> bits below but I think they also largely apply to the marketing=20
> criteria as well):
>
>  =E2=80=A2 I don't think the "version 1.0" requirement is a good one, =
only=20
> because I strongly suspect it wouldn't take me very long to find a ver=
y=20
> reasonable library that for whatever reason is 0.8 or something... so=20
> now it can't be used, unless there is an RFC?

See, I find the 1.0 requirement far less arbitrary than the minimum main=
tainers requirement.  Assuming the library is following semver (most do,=
 mostly), having a 1.0 gives us a reasonable expectation that the API wo=
n't change out from under us in a minor release.  In a 0.x, that is by d=
efinition a risk, making it not necessarily stable enough to trust.  (Th=
ere are indeed some libraries that stay in 0.x land forever, despite bei=
ng well maintained.  These maintainers are Doing It Wrong(tm) and need t=
o stop.)

>  =E2=80=A2 I don't understand what the point of the "Explicitly approv=
ed" list=20
> is, if the point is any and all libraries which meet the acceptance=20
> criteria can be used without asking for permission then they are by=20
> default approved, right?

The criteria are by necessity squishy.  They're guidelines and heuristic=
s, but the PHP ecosystem is far too complex for a series of yes/no binar=
ies to make sense in most cases.  And different people will no doubt int=
erpret different cases differently.

So as a hypothetical, suppose someone tries to mention ramsey/uuid on a =
marketing page.  Another person objects, saying that it isn't important =
enough of a library to the ecosystem as a whole to warrant a mention.  W=
e resolve that conflict by having an RFC to add ramsey/uuid to the "this=
 is definitely OK according to these criteria" list.  If it passes, then=
 we've resolved it: Mentioning ramsey/uuid is now explicitly OK on marke=
ting pages, and if someone objects in the future we can say "look, we al=
ready voted on it and decided it was OK.  Stop fussing."

>  =E2=80=A2 The library should have an active developer community of at=
 least 2=20
> developers, and the library should have an currently active developmen=
t=20
> history of at least 1 year.=20

I see the intent here, to ensure a library isn't going to be abandoned. =
 However, the vast majority of libraries are single-developer.  Even tho=
se that have contributions from others are realistically one-person-proj=
ects.  Looking at ramsey/uuid again (sorry Ben, don't mean to pick on yo=
u), ramsey himself has 705 commits.  Dependabot is #2.  The second human=
 is jmauerhan at 35, so around 5% ish as many, all before 2020.  Does th=
at count as an "active developer community of at least 2"?  I'd say no. =
 But that library is a staple of the ecosystem and has been for over a d=
ecade.  It's not going anywhere.  It's probably more reliably maintained=
 than many 2-3 person projects that never really got off the ground.  So=
 even if we could quantify what counts as "2 active developers", it's st=
ill a fairly poor signal of reliability.

--Larry Garfield