On Fri, Jan 20, 2023 at 12:21 PM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/01/20 12:50, Jakub Zelenka <bu...@php.net> wrote: > > 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. > > This huge PR isn't meant to be merged in one go - as I said, the > previous PRs were smaller, and I'll submit smaller PRs once we agree > what should be in there. > > I think you should clarify in the RFC how this is going to be split and what's the time frame for getting that all in. > > > 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. > > That won't take years, it will take decades. See, my draft PR has 104 > commits currently; if you split each so only one #include gets > touched, and wait a month, that's easily be 50 years - longer than the > PHP project has existed so far. > Your commits are separated by files and are really too small. I didn't mean that. What I was talking about it is to do that single change and apply all dependent changes on it so it still compiles / works and can be proposed as a separate chunk of work. It means if you remove "zend_gc.h" from "zend.h", then your PR would also contain changes that add "zend_gc.h" to "zend_gc.c" and "zend_objects_API.h". So to get "zend.h" to this state in you PR, it would require 9 PR's if I count correctly. There would be some other changes after that obviously but it should be nowhere near to 104... Jakub
