On Thu, Feb 9, 2023 at 1:33 PM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/02/09 19:04, Tim Düsterhus <t...@bastelstu.be> wrote: > > However based on the discussion of the RFC I believe that voters may have > > assumed that a "No" means "A cleanup is not allowed", because several > > participants expressed an active aversion to a cleanup during the > > discussion. As for myself I've certainly had that understanding when > casting > > my vote. > > Voting "NO" means no change - and currently, cleanup is not allowed, > which you can see from the fact that all of my code cleanups were > either rejected or reverted. > That's a poor interpretation of what happened. As Tim alluded, the current status quo is that cleanup is allowed on a case-by-case basis. The particular cases resulting from your PRs were rejected, but this doesn't mean all cases will be. I'm not directly involved in maintenance, but my take on the scenario was that these were rejected and reverted because they caused breakage, whether that was in compiling a spare PHP build, or in extensions that were assuming that using certain headers would slurp in everything they needed. This breakage was unacceptable without an RFC. I saw chatter from a number of folks after the changes were merged about builds no longer compiling; considering the stability of the php-src tree, inability to build will always be a source of alarm. What needs clarification in the RFC you've presented is that a "No" vote means "no change to current processes". Personally, I'd halt the current vote, make the change, and re-start the vote at this point to ensure everyone voting is clear on that point. > > Disallowing a clean-up would require 33% of votes, whereas allowing > > clean-up would require 66% of votes. The status quo "decide on a > > case by case basis" would no longer be legal even without a clear > > agreement. > > It is indeed unfortunate that a supermajority is required for all > primary votes, because in this case, requiring only a simple majority > would be favorable IMO. > A supermajority is required on any change that would lead to backwards incompatibility for either end-users or extension writers. Your proposal is something that would do the latter. Sure a simple majority is ALWAYS more favorable, but the hurdle exists to ensure that everyone pay attention to the BC implications when they vote. > It is not clear whether the current rule is "decide on a case by case > basis"; it has been argued that my code cleanup shall be > rejected/reverted because that would make merging branches harder. > > - If that alone is reason enough to reject/revert a code cleanup > change, then this applies to all kinds of code cleanup, and no code > cleanup is currently allowed. -> "case by case" doesn't count. > > - If that alone is NOT reason enough to reject/revert a code cleanup, > then more reasons need to be brought forward to hold my code > cleanups off. > As I pointed out earlier, the changes previously merged led to breakages when compiling the project. How is that not enough? And dumping a huge bunch of PRs with such changes without first discussing it with maintainers means a lot of effort reviewing — why are your proposed changes more important than any of the other work the various maintainers are doing? This is why they asked for an RFC; something of this magnitude needs discussion, because it impacts everybody already touching the project, the people most familiar with it. The other point that has been brought up multiple times is that it introduces breaking changes for extension maintainers. Should these extensions be relying on one or more "god" headers instead of the specific headers for the symbols they use? Probably not. Will forcing the issue without giving them a chance to review and understand the changes, and have a roadmap for when and how those changes occur be a net positive? No; it will cause a lot of busy work for a lot of people, almost all of whom are volunteers and most of whom would rather be building out user-requested features or fixing user-reported bugs. I'm unsure why that's unclear or not enough for you. -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
