Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125767
Precedence: bulk
MIME-Version: 1.0
References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com>
 <CAEKnhAFaR9O6sirRfG4HYut56N0ZKKqnRknGuTj+fY0XvWeBMg@mail.gmail.com> <4f4e3593-26c2-47c5-a7fe-130a8646081c@app.fastmail.com>
In-Reply-To: <4f4e3593-26c2-47c5-a7fe-130a8646081c@app.fastmail.com>
Date: Tue, 8 Oct 2024 10:46:59 +0100
Message-ID: <CAEKnhAFYPf92XrEgmnFsmN-Y0opneuwB8Hiy=JaLy2z1TPd6Qw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code
To: Jim Winstead <jimw@trainedmonkey.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000074e8ca0623f405b2"
From: bukka@php.net (Jakub Zelenka)

--00000000000074e8ca0623f405b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 8, 2024 at 12:20=E2=80=AFAM Jim Winstead <jimw@trainedmonkey.co=
m> wrote:

> On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote:
>
> Hi,
>
> On Wed, Oct 2, 2024 at 7:38=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.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
> 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 wordi=
ng
> matters. We should be really voting on those PR's rather than create poli=
cy
> 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 chang=
es.
>
>
So there was already note about making changes to policy repo through RFC
in https://wiki.php.net/rfc/policy-repository . Specifically

>  Changes to the policy repository should only be made through a new RFC,
unless it is for fixing spelling mistakes or grammar.

So I think any changes to the policy should link PR to the policy repo in
the same way as we link implementation PR for other changes. What I wanted
to say is that the actual wording should be discussed in the PR but just
the main substance should be described in the RFC. The whole point of this
policy repo is that we don't have to look to every policy RFC but to have a
single place where all policies are defined.

Regards

Jakub

--00000000000074e8ca0623f405b2
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 Tue, Oct 8, 2024 at 12:20=E2=80=AF=
AM Jim Winstead &lt;<a href=3D"mailto:jimw@trainedmonkey.com">jimw@trainedm=
onkey.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"><div class=3D"msg-3665532502750577866"><u></u><div><div style=3D=
"font-family:Arial">On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote:<b=
r></div><blockquote type=3D"cite" id=3D"m_-3665532502750577866qt"><div dir=
=3D"ltr"><div>Hi,<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">On W=
ed, Oct 2, 2024 at 7:38=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:lar=
ry@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com</a>&gt; wrote=
:<br></div><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>Since Jim&#39;s RFC propos=
al was criticized for being too vague, I hereby offer a somewhat more presc=
riptive policy proposal on using 3rd party code.=C2=A0 (With JIm&#39;s bles=
sing.)=C2=A0 It&#39;s still more heuristics than rules, but I think that=
9;s the right approach generally.=C2=A0 It also includes a voting mechanism=
 to resolve edge cases when they come up.<br></div><div><br></div><div>I=
9;m sure we&#39;ll bikeshed it to death, but please keep an open mind about=
 the concept in the first place.=C2=A0 PHP is more than just php-src, and t=
hat&#39;s a good thing.=C2=A0 We need to catch up with that reality, while =
at the same time maintaining a reasonable neutrality about projects Interna=
ls doesn&#39;t manage directly.<br></div><div><br></div><div><a href=3D"htt=
ps://wiki.php.net/rfc/third-party-code" rel=3D"noreferrer" 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 introduc=
ing the basic idea and create a PR against policies repo because that&#39;s=
 where the wording matters. We should be really voting on those PR&#39;s ra=
ther than create policy RFC and then create PR that might have a different =
wording...<br></div></div></div></blockquote><div style=3D"font-family:Aria=
l"><br></div><div style=3D"font-family:Arial">That would seem to be introdu=
cing 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.=
<br></div><div style=3D"font-family:Arial"><br></div><div style=3D"font-fam=
ily:Arial">Maybe policy RFCs like this should have accompanying implementat=
ion PRs like many of the non-policy RFCs do, but I&#39;m not sure that voti=
ng on PRs for policy changes makes any more sense than voting on PRs for co=
de changes.<br></div><div style=3D"font-family:Arial"><br></div></div></div=
></blockquote><div><br></div><div>So there was already note about making ch=
anges to policy repo through RFC in <a href=3D"https://wiki.php.net/rfc/pol=
icy-repository">https://wiki.php.net/rfc/policy-repository</a> . Specifical=
ly</div><div><br></div><div>&gt;=C2=A0=C2=A0Changes to the policy repositor=
y should only be made through a new RFC, unless it is for fixing spelling m=
istakes or grammar.</div><div><br></div><div>So I think any changes to the =
policy should link PR to the policy repo in the same way as we link impleme=
ntation PR for other changes. What I wanted to say is that the actual wordi=
ng should be discussed in the PR but just the main substance should be desc=
ribed in the RFC. The whole point of this policy repo is that we don&#39;t =
have to look to every policy RFC but to have a single place where all polic=
ies are defined.</div><div><br></div><div>Regards</div><div><br></div><div>=
Jakub</div></div></div>

--00000000000074e8ca0623f405b2--