Hey Max and Dmitry, > Am 28.02.2023 um 23:34 schrieb Dmitry Stogov <dmitrysto...@gmail.com>: > > On Wed, Mar 1, 2023 at 1:21 AM Max Kellermann <max+...@blarg.de> wrote: > >> On 2023/02/28 22:31, Dmitry Stogov <dmitrysto...@gmail.com> wrote: >>> https://github.com/php/php-src/commit/0270a1e54c0285fa3c89ee2b0120073ef57ab5fa >> >> This kind of change was favored by a supermajority. >> >> You argue that this supermajority vote is irrelevant, and formally it >> indeed is, but pondering about formalities is kind of ignorant against >> the now well-known community opinion. >> >>> https://github.com/php/php-src/commit/b98f18e7c3838cf587a1b6d0f033b89e9909c79d >> >> No vote was made on this, therefore this doesn't violate any community >> rules, does it? >> > > Please reread https://wiki.php.net/RFC/voting#voting > RFC is accepted by a supermajority of the primary vote. > The secondary votes may be used to make decisions about implementation > details. > > Thanks. Dmitry.
In this case, while the primary concern of the RFC was rejected, I think it's pretty clear, that there was a supermajority for something specific. I do agree, that the topic, given hat it conflicts with the rules, a mail to internals on that topic should have been sent. I did vote no on that topic, however I still think there was some mandate by the community that this is wanted. I would thus not make too much of a fuss on these grounds about the splitting. >> >> If you think this should be reverted, explain why. >> >>> https://github.com/php/php-src/commit/42577c6b6b7577c57c161ee4a74cb193382bf1e0 >> >> Favored by supermajority, see above. >> >>> https://github.com/php/php-src/commit/c7637ed1c03f556c6fb65884cfc5bfea4920b1c7 >> >> No vote, no rule violation, see above. This is no violation and I think Dmitrys tone was a bit too accusing for that. But I also strongly disagree with that change. Let's revert it. Quickly seeing which number is which type is quite valuable for debugging. By now I know most numbers by heart, but most people won't. >>> https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60 >> >> As you see in the commit message, this implements an (unwritten) rule >> cited by Nikita Popov (which is now written as of >> https://github.com/php/php-src/pull/10630). I personally don't agree >> with this rule (there's a thread on this mailing list about it), and I >> would favor reverting this commit - I only submitted this trying to >> help with implementing a rule even though I don't agree with it. >> >> If this gets reverted, then https://github.com/php/php-src/pull/10630 >> should be reverted as well. Again, not my opinion, I'm just trying to >> help implement somebody else's opinion. No, it should not. It makes a lot of sense. It's however not a hard rule, but a guideline. Applying these changes to ZEND_API though always shall be evaluated with due care. In this specific instance, a fairly new API I think nobody uses yet, it's sort of acceptable. I wouldn't mind reverting it though >> >> Max >> Max, while it's nice to see a couple cleanups in the PHP codebase, I would like to ask you to be a bit less quick at moving things around. There's value in having a codebase evaluate slowly. Obviously not at the cost of progress, new features etc.. Keep in mind, that at least extension authors will need to work with the php-src codebase of version 8.2 until probably 7 years in the future (basically until PHP is EOL on all Linux distributions). They will appreciate not looking at a vastly different codebases. Finally, these sorts of code moves are also making a git blame harder to track back. Thanks, Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
