On Mon, Feb 13, 2023 at 11:35 AM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/02/13 01:58, "G. P. B." <george.bany...@gmail.com> wrote: > > We have had completely broken builds for longer days due to some other > > random changes, and we didn't revert them but fixed them as a follow-up. > > We still, for over 6 months now, have a "broken" ASAN build due to phpdbg > > messing up the analyser and crashing the test runner on 8.2 and master, > > something that multiple core devs, me included, need to work around by > > monkey patching the run-test.php file. > > I had a feeling there are double standards at play. The way my work > was dealt with is unprecedented! > > In the git history, I could not find any other set of PRs that was > reverted completely just for a minor one-line issue. > > > Stuff breaks all the time, and every breakage is, of course, a mistake > that should have been handled with more care, and something to learn > from. Sometimes, a revert is the right solution, but in my case, the > (demand of a) revert was unreasonable and hasty. > > > > As a final note, if the complaint had been made by anyone else other than > > Dmitry, I doubt these changes would have been reverted, and can we please > > stop pretending otherwise. > > I forget one include, break an exotic build in master branch, Dmitry > demands complete revert of 4 PRs / 61 commits (60 of which are > unrelated to the breakage). > > Dmitry breaks the whole build for everybody (including the CI) and > introduces a crash bug, merged through all three branches > (https://github.com/php/php-src/commit/a21195650e53), no revert. > > (Don't misunderstand, everybody makes mistakes, I just point out the > obvious double standard.) > > Then everybody is raving about my include comments and forward > declarations, yet the PHP code base has many of these. Turns out > those who complained the loudest have authored some of these in the > past. > > Max > Max, It's OK when commits are reverted. You are working in a common repository, and if your commits become stoppers for others they have to be reverted. Some of my commits were reverted as well. Having too many dependent commits and inability to revert a single one became an additional trouble and drew more attention to things you are doing... I didn't care about a single header change, but I do care about 100 dependent commits. After all, this includes cleanup is really questionable, and the current vote result shows that is not my sole opinion. Personally, I think this work might be very welcome during PHP-7.0 development together with other re-factoring(s). Massive permutation changes in a minor release are not acceptable for me. Maybe it makes sense to target them to PHP-9.0 Thanks. Dmitry.
