On 2023/02/13 10:28, Dmitry Stogov <dmitrysto...@gmail.com> wrote: > 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.
That doesn't explain why you demanded to revert everything instead of applying my trivial single-line fix. > 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. I don't get it, what's your point here? The fact that these dependencies exist is a result of the unclean state of the PHP code base, something my work aims to improve. The number of dependencies after my PRs was lower than before, and that's good. The "inability to revert a single one" is not a problem that needed to be solved, because a revert was never necessary - there was a trivial fix (that did work, contrary to your assertion). > 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 The vote is not about WHEN this cleanup can be done - it's about WHETHER at all. Voting "yes" does not imply that this must be done for 8.3. The RFC suggests that it could be 8.3 or 9.0, but that decision is not part of the vote. Voting "no" means you never want this cleanup to happen, ever, not for 8.3 and not for 9.0. So if you're not really opposed to such a kind of cleanup in general, don't vote "no". Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
