Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125764
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: Mon, 7 Oct 2024 10:54:02 +0100
Message-ID: <CAEKnhAFaR9O6sirRfG4HYut56N0ZKKqnRknGuTj+fY0XvWeBMg@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="000000000000e1d9bb0623e000da"
From: bukka@php.net (Jakub Zelenka)

--000000000000e1d9bb0623e000da
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Oct 2, 2024 at 7: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
>
>
I think it would be better to have just a light RFC introducing the basic
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 create policy
RFC and then create PR that might have a different wording...

Regards

Jakub

--000000000000e1d9bb0623e000da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
On Wed, Oct 2, 2024 at 7:38=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto=
:larry@garfieldtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">S=
ince Jim&#39;s RFC proposal was criticized for being too vague, I hereby of=
fer a somewhat more prescriptive policy proposal on using 3rd party code.=
=C2=A0 (With JIm&#39;s blessing.)=C2=A0 It&#39;s still more heuristics 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 come 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></bloc=
kquote><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 policies repo becaus=
e that&#39;s where the wording matters. We should be really voting on those=
 PR&#39;s rather than create policy RFC and then create PR that might have =
a different wording...</div><div><br></div><div>Regards</div><div><br></div=
><div>Jakub</div></div></div>

--000000000000e1d9bb0623e000da--