On Fri, Jan 20, 2023 at 11:15 AM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/01/20 11:52, Jakub Zelenka <bu...@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
