Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119367
MIME-Version: 1.0
References: <Y8U9B4AVP/R7vazI@swift.blarg.de> <CAFPFaM+FpJj0=Urdz-JUihtNENC_DbG+cKbwwiVNg4GNvZrdZA@mail.gmail.com>
 <Y8e1VLXmnZP66dSg@swift.blarg.de> <CAFPFaMJPt7ZfvfYmoWPGCfDuNW1tLPKwpxHaoy5+k3-RRaXovA@mail.gmail.com>
 <Y8fe2DQqcB7uJhK8@swift.blarg.de> <192ba7b6-dcf0-e2da-c99e-cbad40519e27@gmx.de>
 <Y8gIW3x3KLvrj/H7@swift.blarg.de> <CAEKnhAFmznONstO4Lbb=5C6sieM=ZpAD_EzpSf75AmgEFmpHiA@mail.gmail.com>
 <Y8pqSmpz4hUFY72u@swift.blarg.de> <CAEKnhAHfruX+u_LLQh0_u0uAMMaX0a8VWjG0g_gS2KLH4oq6Xg@mail.gmail.com>
 <Y8p3ufDDY4mem04V@swift.blarg.de>
In-Reply-To: <Y8p3ufDDY4mem04V@swift.blarg.de>
Date: Fri, 20 Jan 2023 11:50:58 +0000
Message-ID: <CAEKnhAGQokbdNW8pQfpkinz-ZsrsUkPWFZfFk1sCzOT6N__yxA@mail.gmail.com>
To: Max Kellermann <max+php@blarg.de>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000056b4bd05f2b0aa0e"
Subject: Re: [PHP-DEV] RFC: rules for #include directives
From: bukka@php.net (Jakub Zelenka)

--00000000000056b4bd05f2b0aa0e
Content-Type: text/plain; charset="UTF-8"

On Fri, Jan 20, 2023 at 11:15 AM Max Kellermann <max+php@blarg.de> wrote:

> On 2023/01/20 11:52, Jakub Zelenka <bukka@php.net> wrote:
> > Reduce the diff to absolute minimum to prevent potential conflict. I
> think
> > it would be more acceptable if there was a plan that will get us there in
> > multiple releases rather than do one big bang change.
>
> My draft PR currently contains 104 very small commits, one for each
> library that I fixed.
>
>
That's exactly it's too big PR that is changing too much which might result
exactly to the mentioned concerns about breaking some untested builds and
it's very hard to track for dev what actually changed.

>
> > That said I think it would be maybe more sensible what I mentioned
> > above and that's to split the work to multiple steps over the years.
>
> I don't know what you mean by that.  Cleaning up a code base is
> incremental work; I have 104 of those splitted steps in my branch, and
> many more steps may follow.  This will take years, or rather: will
> never be finished, because code can always be improved some more.
>
> Do you mean I should work more slowly?  I should submit my patches
> more slowly?  In smaller PRs?  Wait more between PRs?
>
>
Yeah exactly all of that. I looked to the PR and it's combining lots of
different changes. It's mainly because all changes in "zend.h" and
"zend_API.h" are done in one go. I think it would be just better to propose
change of a single header replaced in them instead. For example just remove
"zend_alloc.h" from "zend.h" and all needed changes for that. Then wait a
month and propose removal "zend_gc.h" from "zend.h". Then wait another
month, propose other include and so on. It will probably take years to get
all changes in but in this way it's much safer, more in my opinion and. I
would also suggest to limit any re-ordering of headers as well as the
mentioned comments so diff is minimal.

By the way all of this is just my opinion but think that less invasive
changes might more likely to get this accepted.

Regards

Jakub

--00000000000056b4bd05f2b0aa0e--