Afternoon Zeev, > I'll happily take your interpretation of it. No hard feelings.
Thanks, you know I don't have another way of being :) When I refer to "you", I really mean you and Dmitry, while you don't have a hive mind, you do act as one, or for one another in a lot of cases. If I'm wrong about that, I apologise. > I would say that Dmitry has by far the best track record of fixing any outstanding issues I would agree, however it was Dmitry that wrote the RFC, and Dmitry that said it had leaks ... what am I supposed to think about that ? If someone does a patch for /Zend and it leaks or is suboptimal in any way, it does not land on Dmitry's say so, but it's okay for him to merge stuff with known defects ... I think the problem there is quite clear. > Functionality isn't everything. Very few extensions have a technical requirement to be bundled - it's much more of a question of promotion. So you want to say that for FFI to be used, it had to be included in php-src ? That's nonsense, the kind of people who are capable of using FFI are also capable of installing an extension. From my perspective it had no justification for being merged at all, but there were very good reasons to keep it out of php-src not least the slim majority on which it was merged. > 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. So it sounds like we agree here, it was pushed into php-src on an unacceptable margin. > I categorically disagree that it is an incomplete feature; I presume you're saying this because it currently supports Linux x86/x64? This sounds disingenuous to me, you are trying to make it sound ready before it actually is. > 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 That's true, but Windows is a core platform for PHP, if you haven't got Windows, you got nothing. I wouldn't make such a fuss about windows or fancy architectures, if I thought there was anyone around who could actually implement them, as far as I know there isn't and if they are unimportant to dmitry and yourself, then it won't get done. > 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. Check the date on the rfc, nothing is happening suddenly. > I'm not fine with rushing to hastily change the rules (while breaking the existing ones) to counter a specific RFC. As I have already explained, I'm prompted to act because of a pattern of behaviour and decisions that I find questionable, and so do others ... and by your own admission, so do you ... I should make clear that I think FFI is really cool although I haven't found time to play with it yet, and clearly I want us to have a JIT, and marvel at the achievement. I can't wait to start reading it (again) and trying to understand. This is not about one or two RFCs, but making simple changes to give us more confidence in the decisions we are all making, and it certainly isn't an attack on you or Dmitry, nothing of the sort ... I think we don't really have anything to argue about, and to reiterate, I will be taking this RFC to vote. Cheers Joe On Thu, 31 Jan 2019 at 16:13, Zeev Suraski <z...@php.net> wrote: > > > 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 >
