On 2023/02/28 21:16, Dmitry Stogov <dmitrysto...@gmail.com> wrote: > Recently we voted for inluce cleanup RFC > https://wiki.php.net/rfc/include_cleanup and it was declined. > Despite that a series of code refactoring commits from Max were silently > merged into the master. > As this is a violation of the community rules and we should do something.
I don't get any of that. Please be more specific. Which community rule was violated by whom? In your opinion, what exactly does the outcome of the vote mean? Does it mean that include cleanups are now forbidden (despite being wanted by the majority of voters)? Or does it mean that nothing changes because no new rule has taken effect? (I asked that already, but nobody replied.) What do you mean by "merged silently"? All of my PRs were submitted in the public, and everybody had a chance to comment on these (which you did, for example, in https://github.com/php/php-src/pull/10641). It usually takes a week or so before they are merged. If you feel that is not enough time, why not post a RFC and vote on a mandatory minimum review duration for all merges/pushes? Though, by contrast, you merge most of your own PRs shortly after you create them without any code review. Quite often, you even push commits without any PR. In my opinion, that's more "silent" than my work, don't you agree? Which specific commits do you wish to revert? Is this about include cleanups (none of which were merged) or about header splitting (which a supermajority voted for) or about other kinds of code refactoring (which was not voted on)? > Then most of the work should be done in a separate branch and merged > into the master all together after a final review. The problem with merge conflicts was your major complaint about branch merging (and that was only about merging bug fixes, not about merging two volatile branches together) - and now you suggest something that will certainly lead to merge conflicts because your suggestion postpones the big merge for as long as possible. That will inflict major pain to PHP maintainers (though not to outside contributors like me, so why would I care). Another big problem: if it's uncertain that some changes ever get merged, because the "final review" may reject it after months or years of work, nobody will ever want to clean up the PHP code again, because it's very likely that you'll veto it again, and then all the time would be wasted. Not a great prospect. If you want to scare away contributors, that's how to do it. My opinion is: if a patch improves a piece of code, it should be merged. Of course, whether something is an improvement is debatable; but postponing that decision is pointless and harmful. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
