Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125765
Feedback-ID: ia2404087:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 07 Oct 2024 16:17:37 -0700
To: internals@lists.php.net
Message-ID: <4f4e3593-26c2-47c5-a7fe-130a8646081c@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAFaR9O6sirRfG4HYut56N0ZKKqnRknGuTj+fY0XvWeBMg@mail.gmail.com>
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <CAEKnhAFaR9O6sirRfG4HYut56N0ZKKqnRknGuTj+fY0XvWeBMg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
Content-Type: multipart/alternative;
 boundary=1b694eed3cf6497da7b93e2847a58f4f
From: jimw@trainedmonkey.com ("Jim Winstead")

--1b694eed3cf6497da7b93e2847a58f4f
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote:
> Hi,
>=20
> On Wed, Oct 2, 2024 at 7:38=E2=80=AFPM Larry Garfield <larry@garfieldt=
ech.com> 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 c=
ode.  (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.
>>=20
>> I'm sure we'll bikeshed it to death, but please keep an open mind abo=
ut the concept in the first place.  PHP is more than just php-src, and t=
hat'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.
>>=20
>> https://wiki.php.net/rfc/third-party-code
>=20
> I think it would be better to have just a light RFC introducing the ba=
sic idea and create a PR against policies repo because that's where the =
wording matters. We should be really voting on those PR's rather than cr=
eate policy RFC and then create PR that might have a different wording...

That would seem to be introducing a whole new process for making policy =
changes, because right now there is no voting process for PRs for any of=
 the PHP organization repositories.

Maybe policy RFCs like this should have accompanying implementation PRs =
like many of the non-policy RFCs do, but I'm not sure that voting on PRs=
 for policy changes makes any more sense than voting on PRs for code cha=
nges.

Jim
--1b694eed3cf6497da7b93e2847a58f4f
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 style=3D"font-family:Arial;">On Mon, Oct 7, 2024=
, at 2:54 AM, Jakub Zelenka wrote:<br></div><blockquote type=3D"cite" id=
=3D"qt" style=3D""><div dir=3D"ltr"><div>Hi,<br></div><div dir=3D"ltr"><=
br></div><div dir=3D"ltr">On Wed, Oct 2, 2024 at 7:38=E2=80=AFPM Larry G=
arfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldtech=
.com</a>&gt; wrote:<br></div><div class=3D"qt-gmail_quote"><blockquote c=
lass=3D"qt-gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-=
bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:sol=
id;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>Since Ji=
m's RFC proposal was criticized for being too vague, I hereby offer a so=
mewhat more prescriptive policy proposal on using 3rd party code.&nbsp; =
(With JIm's blessing.)&nbsp; It's still more heuristics than rules, but =
I think that's the right approach generally.&nbsp; It also includes a vo=
ting mechanism to resolve edge cases when they come up.<br></div><div><b=
r></div><div>I'm sure we'll bikeshed it to death, but please keep an ope=
n mind about the concept in the first place.&nbsp; PHP is more than just=
 php-src, and that's a good thing.&nbsp; We need to catch up with that r=
eality, while at the same time maintaining a reasonable neutrality about=
 projects Internals doesn't manage directly.<br></div><div><br></div><di=
v><a href=3D"https://wiki.php.net/rfc/third-party-code" rel=3D"noreferre=
r" target=3D"_blank">https://wiki.php.net/rfc/third-party-code</a><br></=
div></blockquote><div><br></div><div>I think it would be better to have =
just a light RFC introducing the basic idea and create a PR against poli=
cies repo because that's where the wording matters. We should be really =
voting on those PR's rather than create policy RFC and then create PR th=
at might have a different wording...<br></div></div></div></blockquote><=
div style=3D"font-family:Arial;"><br></div><div style=3D"font-family:Ari=
al;">That would seem to be introducing a whole new process for making po=
licy changes, because right now there is no voting process for PRs for a=
ny of the PHP organization repositories.<br></div><div style=3D"font-fam=
ily:Arial;"><br></div><div style=3D"font-family:Arial;">Maybe policy RFC=
s like this should have accompanying implementation PRs like many of the=
 non-policy RFCs do, but I'm not sure that voting on PRs for policy chan=
ges makes any more sense than voting on PRs for code changes.<br></div><=
div style=3D"font-family:Arial;"><br></div><div style=3D"font-family:Ari=
al;">Jim<br></div></body></html>
--1b694eed3cf6497da7b93e2847a58f4f--