On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins <krak...@gmail.com> wrote:
> Afternoon Zeev, > > I'm going to use unambiguous and direct language to make sure my intentions > and concerns are communicated clearly, you can either receive this as a > personal attack, or as a contributor being direct, I would prefer the > latter. > I fail to see how in the way it was written it could not be taken as a personal attack, but since you wrote it, I'll happily take your interpretation of it. No hard feelings. > You pushed FFI into php-src on a simple majority I didn't push FFI. Yes, it was my idea to invest in it a year or two ago, but Dmitry took it from A to Z. Contrary to popular belief, we're not the same person, nor do we have a hive mind... > was > incomplete (with leaks), I would say that Dmitry has by far the best track record of fixing any outstanding issues - not only with his code, but with the code of mostly everyone else contributing to PHP, so if there's one contributor where this isn't something to worry about - that's him. > and had zero justification for being included in > php-src - it didn't require any internal API's and can function just fine > as a PECL extension Functionality isn't everything. Very few extensions have a technical requirement to be bundled - it's much more of a question of promotion. > still you pushed through with the RFC and it was > accepted on a simple majority. > I did not push this RFC in any way, nor did I even try to ask others to vote for it (which I would have if I was 'pushing' it). I actually agree with you that the fact it didn't clear a 2/3 vote, and with a hefty margin - is not very ideal. You are now trying to push JIT into php-src on the same slim, clearly > unacceptable majority, and even if you change the majority requirements, > what's worse is you want to include it in a minor version. Once again, this > is an incomplete feature, failing to support the architectures we support > and declaring them unimportant. I categorically disagree that it is an incomplete feature; I presume you're saying this because it currently supports Linux x86/x64? Does that make our mod_php feature incomplete because it doesn't support Windows? Is Swoole incomplete because it only supports Linux and Mac? It's not unusual for complicated pieces of software to first be available for specific subsets of platforms, and than gradually be ported to others. It may not be the intention, but it's difficult not to take calling it "incomplete" as something other than disparaging the mind-boggling levels of effort that went into it over the last 7 years. Seriously, it's akin to someone handing us a goose that lays golden eggs, for free, and us complaining that they require these special weeds to feed on. You are pushing PHP towards a future where > there is effectively a single contributor, possibly two, able to make > changes to Zend+Opcache; You are changing core parts of PHP too fast and > making other contributors, including the maintainers of external tooling > which the ecosystem requires to function, uncomfortable. > These are valid concerns, which is why they are fact covered in the RFC. Of course, it would be possible to make changes to the engine/OPcache without maintaining JIT - which would in turn break only JIT, in case we reach a situation where JIT has no maintainers, or they're unable to keep up with the changes. The architecture is purposely designed in a way that the engine remains independent of the JIT layer. I really don't think you have bad intentions, but think our processes are > allowing us to make questionable decisions for the whole project, and this > I intend to resolve, regardless of your next actions, before any more > questionable decisions can be taken. I think there were questionable decisions that happened long before FFI/JIT, and still, it didn't cross my mind to suddenly change the rules for them specifically. I'm fine with waiting with the JIT vote until we figure out voting. I don't think we're in any rush as far as the decision is concerned (and we can start discussing anyway). I'm not fine with rushing to hastily change the rules (while breaking the existing ones) to counter a specific RFC. Zeev
