Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103934
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=MfZWEHelbatFN7hFoSxMS/vD9nX7uP7PuUBlFpRsV5sx03G2DZK6b0k1RrPoyP
	+CZJ80nzCbK3AAszGtcgT0U3X72dfjCee3vcOmSbm4Gtg1elLLM/WTedOPWjK2Oa
	+tu4vvhAHKs6PnppuY1lpbX1kFtKgc+dvIIA7zTjGiatU=;
MIME-Version: 1.0
References: <CAOwTYAsePeRLZZVK=QKftoOtug2_F=5bsti56z2mJfBXP0u4rw@mail.gmail.com> <DM6PR02MB5594D2DE0A166B13024E44B9AC910@DM6PR02MB5594.namprd02.prod.outlook.com> <CAOwTYAtr=eoRxAR4yOT_a-zuw_m9_wvNU-01eX3AyyQd5Rgw2w@mail.gmail.com> <DM6PR02MB5594464D33F2A0A02D747D6BAC910@DM6PR02MB5594.namprd02.prod.outlook.com> <CAOwTYAvnRaszSVi9Ua0AGdnMP5YCRjV7UGAnyk9DJ+qfXLG26Q@mail.gmail.com> <CAJHtznySqZY2WrU32faAcOE+tuo8v716BHmZtynCqRseWn1-cQ@mail.gmail.com> <CAOwTYAuTaLha3CAFPyj6xsXgKfhROgbqLMyhb-6R+4j5wy_PYw@mail.gmail.com>
In-Reply-To: <CAOwTYAuTaLha3CAFPyj6xsXgKfhROgbqLMyhb-6R+4j5wy_PYw@mail.gmail.com>
Date: Thu, 31 Jan 2019 18:43:33 +0200
Message-ID: <CAJHtznxDyT+PdeZBCnLZ3C3ezs3MLMaZED3t-qeZdqz6P2yh7g@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e14aa60580c3baa4"
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
From: zeev@php.net (Zeev Suraski)

--000000000000e14aa60580c3baa4
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 5:56 PM Joe Watkins <krakjoe@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

--000000000000e14aa60580c3baa4--