Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129070
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <CAEKnhAFig86RdM0tyzPQNAANSjZ2M2RsC-7qPLkYN2gS04O6og@mail.gmail.com>
 <57fb1051c9ca4df290556fe0c16a6a37@bastelstu.be> <CAEKnhAFKuvxrh-vWwUcfaS7T3520vBqO_P8wrJSEgUhbT0uJXQ@mail.gmail.com>
In-Reply-To: <CAEKnhAFKuvxrh-vWwUcfaS7T3520vBqO_P8wrJSEgUhbT0uJXQ@mail.gmail.com>
Date: Tue, 4 Nov 2025 14:47:54 +0100
Message-ID: <CAEKnhAFKjhwugdaPrmUmD_oSHUKxvRipsq08Bg-Or6E8+ki3JQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Policy release process update
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d0dd430642c514ac"
From: bukka@php.net (Jakub Zelenka)

--000000000000d0dd430642c514ac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 4, 2025 at 2:34=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote:

> On Tue, Nov 4, 2025 at 2:23=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:
>
>> Hi
>>
>> Am 2025-11-02 13:38, schrieb Jakub Zelenka:
>> > Just wanted to give heads up that I plan to open voting tomorrow.
>>
>> I'm seeing there were some additional comments on the GitHub PR:
>>
>> https://github.com/php/policies/pull/19#pullrequestreview-3413485445
>>
>> As I had noted on the PR before
>> (https://github.com/php/policies/pull/19#discussion_r2425684839) PRs are
>> a terrible medium of discussion. And especially when the list is not
>> actively kept in loop, folks will inevitably miss out on some of the
>> discussion. That's why I mostly refused to discuss my policy RFCs on
>> GitHub, instead asking folks to come to the mailing list - which is the
>> accepted official discussion medium of RFCs - to have everything in a
>> single location.
>>
>> I appreciate that you provided plenty of heads up for folks to review
>> the text after the initial (long) GitHub discussion, but after your
>> announcement from https://news-web.php.net/php.internals/128819 I would
>> kindly request that the ongoing discussion is kept on the list so that
>> everyone has a chance to see it.
>
>
> I think GH is good to shape the initial policy as it's easier to comment
> on specific parts there but agree that the main discussion should happen =
on
> the list once announced. But you need to ask the ones that are commenting
> there. I was just replaying...
>
>
To bring the discussion back here, there were two concerns:

1. That `Internal API compatibility breaks are NOT RECOMMENDED.` is not the
current practice. I always thought that it is our current practice to limit
the internal API breaks to minimum so we don't in general don't recommend
those. But if others disagree that it's our current practice, I'm happy to
remove it. Personally I think it's good to have such recommendation because
internal API breaks often delay the release usage if some important
extension does not get updated. We had a very good example in imagick.

2. The already existing rule RM can "Decide which bug fixes can be applied
to a release, within the cases defined in this RFC" was questioned if it
should stay and if RM ever used it. I think it should stay because it's
good to have some rule about who can decide a potential disagreement
whether the bug should be merged to the specific branch. This part has been
already in policy so there's not much to do here.

Kind regards,

Jakub

--000000000000d0dd430642c514ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Nov 4, 2025 at 2:34=E2=80=AFPM Ja=
kub Zelenka &lt;<a href=3D"mailto:bukka@php.net">bukka@php.net</a>&gt; wrot=
e:</div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Tue, =
Nov 4, 2025 at 2:23=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim=
@bastelstu.be" target=3D"_blank">tim@bastelstu.be</a>&gt; wrote:</div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<=
br>
<br>
Am 2025-11-02 13:38, schrieb Jakub Zelenka:<br>
&gt; Just wanted to give heads up that I plan to open voting tomorrow.<br>
<br>
I&#39;m seeing there were some additional comments on the GitHub PR:<br>
<br>
<a href=3D"https://github.com/php/policies/pull/19#pullrequestreview-341348=
5445" rel=3D"noreferrer" target=3D"_blank">https://github.com/php/policies/=
pull/19#pullrequestreview-3413485445</a><br>
<br>
As I had noted on the PR before <br>
(<a href=3D"https://github.com/php/policies/pull/19#discussion_r2425684839"=
 rel=3D"noreferrer" target=3D"_blank">https://github.com/php/policies/pull/=
19#discussion_r2425684839</a>) PRs are <br>
a terrible medium of discussion. And especially when the list is not <br>
actively kept in loop, folks will inevitably miss out on some of the <br>
discussion. That&#39;s why I mostly refused to discuss my policy RFCs on <b=
r>
GitHub, instead asking folks to come to the mailing list - which is the <br=
>
accepted official discussion medium of RFCs - to have everything in a <br>
single location.<br>
<br>
I appreciate that you provided plenty of heads up for folks to review <br>
the text after the initial (long) GitHub discussion, but after your <br>
announcement from <a href=3D"https://news-web.php.net/php.internals/128819"=
 rel=3D"noreferrer" target=3D"_blank">https://news-web.php.net/php.internal=
s/128819</a> I would <br>
kindly request that the ongoing discussion is kept on the list so that <br>
everyone has a chance to see it.</blockquote><div><br></div><div>I think GH=
 is good to shape the initial policy as it&#39;s easier to comment on speci=
fic parts there but agree that the main discussion should happen on the lis=
t once announced. But you need to ask the ones that are commenting there. I=
 was just replaying...</div><div><br></div></div></div></blockquote><div><b=
r></div><div>To bring the discussion back here, there were two concerns:<br=
><br>1. That `Internal API compatibility breaks are NOT RECOMMENDED.` is no=
t the current practice. I always thought that it is our current practice to=
 limit the internal API breaks to minimum so we don&#39;t in general don=
9;t recommend those. But if others disagree that it&#39;s our current pract=
ice, I&#39;m happy to remove it. Personally I think it&#39;s good to have s=
uch recommendation because internal API breaks often delay the release usag=
e if some important extension does not get updated. We had a very good exam=
ple in imagick.</div><div><br></div><div>2. The already existing rule RM ca=
n &quot;Decide which bug fixes can be applied to a release, within the case=
s defined in this RFC&quot; was questioned if it should stay and if RM ever=
 used it. I think it should stay because it&#39;s good to have some rule ab=
out who can decide a potential disagreement whether the bug should be merge=
d to the specific branch. This part has been already in policy so there&#39=
;s not much to do here.</div><div><br></div><div>Kind regards,</div><div><b=
r></div><div>Jakub</div></div></div>

--000000000000d0dd430642c514ac--