Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75763
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2de3e71e35addbf16b2dc622f4c81eff@mail.gmail.com>
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com>
	<CAEZPtU52X737iUZgKUJbT0bb9z-cr_EYfxMcmv804AhnTpLnhg@mail.gmail.com>
	<CAMUwpuQrQd-ROPN0oRk37+U1JFnz487__vZxGjSC5f-TcYyfqg@mail.gmail.com>
	<2de3e71e35addbf16b2dc622f4c81eff@mail.gmail.com>
Date: Mon, 21 Jul 2014 12:18:58 +0200
Message-ID: <CAEZPtU52KbAEFqrerET54CLFgGzq5DnnQLPt5zuo6mOTTvr+-A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Julien Pauli <jpauli@php.net>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Jul 21, 2014 at 10:33 AM, Zeev Suraski <zeev@zend.com> wrote:

> It's absolutely fine to have separate discussions on cleaning APIs, new
> features and any other changes people think we should do, but it absolutely
> has nothing to do with phpng moving into master.  We can take the
> opportunity of a major version to do some cleanups, BUT:

It is obviously not only absolutely fine, it is a requirement. It
should have done before anything else, for obvious reasons.


> 1. It's independent from the phpng effort and RFC.  We should vote on it as
> soon as possible to remove any doubts that do linger in people's minds
> regarding whether at all we're going to use it.

If it is independent from phpng then phpng is nothing more than a (set
of) patches that should be proposed independently and not as a
replacement for master or as base for php-next.

> 2. We should set a due date for this version, so that we don't wait
> indefinitely for things to happen.  We don't have the luxury of 'sitting' on
> phpng for years, IMHO.  This too is an independent question from this RFC.

I wonder when you have been while we were talking about what we
actually like to do and have in php-next. Maybe it was a better
strategic choice to participate in the various efforts to get a clear,
well discussed and designed roadmap rather than doing this massive set
of patches in your corner. And yes, I already said that many times.

>> I just cant believe we won't rework our API , fully and deeply, for
>> PHP-Next.
>
> You're more than welcome to make such proposals and either write patches or
> rally others to write them.  This RFC doesn't preclude any other changes
> happening in PHP.NEXT, it just removes the doubts about this being the basis
> for the next version of PHP.

As a matter of facts, and despite your (team) numerous posts saying
that you had no plan to do what you are proposing here, the efforts
for php-next has simply being stopped to avoid the pain that was the
64bit RFC because of phpng. A RFC that you totally agreed to have in
next as it was earlier this year after having rejecting it for 5.x.
>
> Regarding Dmitry saying that phpng is an experimental branch - that was a
> couple of months ago.

That was last week or at the end of the previous week. Amazingly
enough, at the same time you were saying that phpng was pretty stable
and no more huge changes will happen, many huge changes reached this
branch, and these changes were not bugs fixes. It tells me a lot about
the visibility you have on phpng. I do not mean to offend anyone here
but for what I see here is what we had with opcache, power 20. I do
not want to see that for php-next, or we can just begin to vote for
what will be the next major version once we borked 6 and 7.

> It evolved, it runs apps in parity with 5.6, and it's
> fine to move it to master right now.  The alternative - developing 5.7 on
> master and creating a synchronization hell - sounds like a horrible course
> of action.

Welcome to the world you created for us since you rejected a 200%
stable branch and then killing it by introducing an experimental one,
with a clear goal, from the very beginning, to replace master for the
next major version. This world is not the one I want or wish for the
PHP core.

Now, enough bashing.

What I wish to even consider reviewing or discussing phpng any further:

- clear documentation of the changes and migration plans
- clear roadmap of upcoming changes, even work in progress
- how open you are to changes (cleanup, APIs consistency
"improvements",etc.) in phpng before it is merged, no matter how
- integration of existing patches, blocked now since months by phpng,
and how you plan to support us to merge them in phpng, if it ever
happens.
- actual discussions about what we want for php-next, as performance
is only  very tiny part of the work for php-next


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org