Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103922
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=D3zo6zc2Y/aOAh6W0PHY0DCDmE7KRshngDVK24R3fL2JA82Nw1M0MgJyB5Vx6C
	o+RExWqLkvett6tRaAbEPbwFPvIUayDpPHHrK9EZ02Uv+DNWjAUAYtQ4DgLrVhcT
	GKNxFslxZTjPrmXWROoL/AeLAEyWqry+BAdohzee8oK+8=;
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>
In-Reply-To: <CAOwTYAvnRaszSVi9Ua0AGdnMP5YCRjV7UGAnyk9DJ+qfXLG26Q@mail.gmail.com>
Date: Thu, 31 Jan 2019 17:13:34 +0200
Message-ID: <CAJHtznySqZY2WrU32faAcOE+tuo8v716BHmZtynCqRseWn1-cQ@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fe76d60580c278f2"
Subject: Re: [PHP-DEV] RFC Abolish Narrow Margins
From: zeev@php.net (Zeev Suraski)

--000000000000fe76d60580c278f2
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 31, 2019 at 4:27 PM Joe Watkins <krakjoe@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

--000000000000fe76d60580c278f2--