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. Submitting partial PRs and reordering commits is trivial for me, thanks to my stgit superpowers! > 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. (Remember that Derick Rethans specifically complained here that my work consists of too many small commits? Giggle.) > 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. Meanwhile, all the others will add new "unclean" code faster than I am allowed to clean up. It will produce the same amount of merge problems, only slower. I think you overestimate the gravity of the changes this RFC will do. This isn't a code rewrite, this isn't fragile. If it builds, it's okay. So the worst that can happen is a build breakage with some exotic configuration (like the DTrace breakage my work caused), but these are trivial to fix. If it happens, it demonstrates that PHP's CI is incomplete and should be improved. There is no worst-case scenario that would suggest artificially delaying this work by decades. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
