On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins <krak...@gmail.com> wrote:
> 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. > You are wrong, apology accepted. > > 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. > See separate reply from both Dmitry and me. Sounds like a large part of what brought you to vote against FFI was misunderstanding of the situation. Which I guess can still be blamed on the RFC author, but at least, this concern should be alleviated now. > 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. > Joe, please, this language is counter-productive. Even more so when you're first putting words in my mouth, but also without it. Can we discuss things politely without telling the other party that they're being nonsensical? I did not say that that "it had to be included in php-src in order to be used". Neither does ext/mysqli or any other extension for that matter. I *did* and *am* saying that it will *promote* its usage. As is the case with most promotions - the lack of promotion does not necessarily mean complete and utter failure, but the presence of promotion may yield better results than without it. I very much stand by my statement that bundling extensions in PHP is predominantly about promotion and ease of use, than it is about technical requirements. > 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. > It wasn't such a slim majority, it was 62% IIRC, which is a lot closer to the 2/3 needed than the 1/2 that was defined for it. That said, I think it's sad it didn't clear the vote with a much higher margin - well above 2/3 - and I'm making a cautious bet than misunderstandings around potential leaks may have had something to do with it, and had it been clear that these potential "leaks" are in fact an inherent element of FFI, and not a limitation of the implementation - it would likely have gotten a lot fewer negative votes. > 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. > "Unacceptable" is your statement, not mine. We're not in a black and white world - it's grey. I think that with the current rules, it's 100.0% acceptable. Would I prefer that it cleared the vote with a much higher, 80-90% margin? Yes. For JIT, which is a much bigger deal in every respect compared to FFI, I think it makes sense to take a pause and make sure we have our rules in order before we move forward. > 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. > I can't control what it sounds like to you. I can only control what I say, and I know that I'm saying it with 100% sincerity based on my view of the world and the importance of the different deployment platforms in the PHP space. > 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. > As the person who made PHP a first class citizen under Windows back in the day (based on tons of prior work by Shane Caraveo), I wholeheartedly disagree. Windows support is not *nearly* as important as Linux support, especially not when we deal with production systems - which is what JIT is geared at. Windows it a tiny tiny fraction compared to Linux as far as deployments are concerned. The situation is different when we deal with development - but that's mostly orthogonal to JIT (again, a production feature) - plus recent trends make it even less of an issue, as even a developer running Windows is today more likely to be running PHP in a Linux container/VM, than natively on Windows. 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. > Saying it's "not a priority" is not quite the same as saying it's not important. It's actually not the same at all. Let me bounce back what this whole thread sounds like - not to me, but how I imagine it would sound to Dmitry: "So you worked your behind off for 7 years to get this going. I think we shouldn't even be discussing it, because it's incomplete - because some architecture that a tiny fraction of PHP's users are using for production isn't supported. Get back to us when it's ready. Oh, heads up - I'd also be against admitting this feature to the codebase altogether and will fight against it, as I think it'll be impossible to maintain. But I won't even discuss that with you right now, please spend another 6 months porting it to Windows because I shoot it down." > > > 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. > To use your own words, this sounds disingenuous to me. You know exactly what happened, and why you *suddenly* popped up the RFC from the drawer for immediate voting. The Voting RFC clearly states that the date on the RFC itself is meaningless, and the count begins from the point in time you send an email to the mailing list with your intention to bring that RFC for a vote. That day is today. > 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. > That's regrettable IMHO, regardless of when that happens. However, if it happens before we clear the two week discussion period - I will be ignoring the results of this illegitimate vote, and would be encouraging others to do the same (both the voting process, and whatever the results would be). If you insist on putting it to a vote that's obviously entirely within your right - but please play by the same rules that apply to everyone else and provide us with the required discussion period. Zeev
