RFC: Move phpng to master View as Markdown

Am 21.07.2014 10:33, schrieb Zeev Suraski:

Regarding Dmitry saying that phpng is an experimental branch - that was a
couple of months ago. 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.

I was not able to run PHPUnit using PHPNG at all back when it was first
announced.

I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
week, btw. Only one test fails (due to a change in the output of
print_r() for SplObjectStorage IIRC). This tells me that there was a lot
of progress :-)

Regarding Dmitry saying that phpng is an experimental branch - that was a
couple of months ago. It evolved, it runs apps in parity with 5.6, and
it's
fine to move it to master right now.

Perhaps you could write a summary of what's changed since phpng was
uncovered a couple of months ago? (besides better performance and
greater compatibility with existing PHP) And also update the existing
RFC with the benefits of merging this branch to master, as opposed to
describing the inconvenience of not merging it.

I'm sure that would help keep the discussion on topic and grounded in fact.

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

Hi Julien,

Hi

I can only agree here.

I'd like a clean API. We need to consider PHP-Next jump as an opportunity
to
clean our API and finally have something understandable for a
newcomer, and documented. That's a move nobody dared to take in the
last decade, degrading more and more our codebase in term of
understandability and flexibility. This can't last

I'm more than agree about internal cleanup.
phpng benchmark results proved that we take the right direction and now we
implemented most the ideas we had.
Note that we tried not to change PHP behaviour in any way.
Now it's a good time to start the cleanup work.

Not changing behavior is nice and very hard work to do, so congrats on that one.

If cleaning the API receives "no-go" because the cleanups would
involve swaping some parameters in functions, or turning macros to
inline functions , which drops some little percentage in performance
on some rare compilers, then there will be a problem to me.

We need a trade-off here. We can't leave unreadable code in, should
this code be written in a specific way for performances. We can afford
a little 1% or 2 IMO.

Old features and unused things should be cleaned up.
Quickly caught, impacting the engine :

• Resources are a hell, mixed with zend_lists etc... inconsitstent and
  absolutely PITA to develop with.
• Streams need to be cleaned up and reworked to support full
  asynchronous IOs, which could involve threads, thus engine tied
• Signals have been worked on starting with 5.4 (AFAIR), but never
  activated by default. I guess the actual implementation lacks a bit
  more reflection to be stable, and to finally propose signal managers
  into userland. ext/pcntl should be somehow merged to core, and this as
  well would involve engine work
• TSRM need to find love, or to find a better replacement, which would
  involve a big engine work as well
• ... and so on

Some of the topics above are really big... :)

Macro hell should be reworked as inlined functions, and I'd like we
start supporting C99 as well.

Performance is a userland point.
API, doc, and clean things are developers points, and IMO, they are as
important.

What about merging OPCache to the branch ?
This was talked about at PHP5.5 release, has never happened yet, and
doesn't seem planed. This could have a big impact on the engine
codebase.

What do you mean? isn't it already there.
I'm also going to remove opcache code for old PHP versions in php-next.

I was talking about merging the code bases.
For example, shared memory model from OPCache could be merged into
Zend/ and expose an API one could reuse in extensions needing SHM.
Also, accelerator's code could be merged into Zend/zend_execute and Zend/ZendVM

Julien

I can only agree here.

I'd like a clean API. We need to consider PHP-Next jump as an
opportunity to clean our API and finally have something
understandable for a newcomer, and documented. That's a move nobody
dared to take in the last decade, degrading more and more our
codebase in term of understandability and flexibility. This can't
last

I'm more than agree about internal cleanup. phpng benchmark results
proved that we take the right direction and now we implemented most
the ideas we had. Note that we tried not to change PHP behaviour in
any way. Now it's a good time to start the cleanup work.

Actually, I think that should be done after merging / changing it to
master. Right now, the phpng vs master branch differences are ... rather
large. It'd be good to do additional cleanup in smaller chunks later on
as it makes it a lot easier to review those changes.

cheers,
Derick

I don't think that a cleanup is nearly as important as php-ng is as we stand
currently.

The will be no mercy from the competition.

We can start reworking the API when it hit master.

Cleanup reduces the work, not increase it. Cleanup eases testing,
review and maintenance. I am sorry but I totally fail to understand
why it is not the absolute top goal for next.

--
Pierre

@pierrejoye | http://www.libgd.org

--001a11345984e013cd04feb0d9a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

PHP-Next.

I don't think that a cleanup is nearly as important as php-ng is as we
stand currently.

The will be no mercy from the competition.

We can start reworking the API when it hit master.

--001a11345984e013cd04feb0d9a1--

I want to remind that the last attempt of PHP 6 died because it was mostly
unmaintained as "master" for a long time and we continued to postpone
it. We should try to not again make a "big move" but take "babysteps"
and focus on phpng and 64bit as the major features and not maintain a
branch while we are doing 5.7. This will undoubtful lead to a similar
"abundance" of the master branch as we just don't have the ressources
to maintain more branches (a point already made when we discussed the
release plan).

I think we should consider steps to make phpng the major development
branch within the year and if stabelizing it within the year possible,
make it the next release.

He just asks if we will have a 5.7 release while working on the next major
in master.
I don't think that we can release the php-next under a years, so I think
that an 5.7 could be warranted (to keep up with our roadmap), but depends
on wether or not we have enough new (BC-safe) features.

Clearly yes, for two reasons:

• we do one x.y+1 every year
• php-next will take 2-3 years, ideally (while I have doubts when I
  see what is going on now)

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

He just asks if we will have a 5.7 release while working on the next major
in master.

I don't think that we can release the php-next under a years, so I think
that an 5.7 could be warranted (to keep up with our roadmap), but depends
on wether or not we have enough new (BC-safe) features.

I don’t see a reason of why we can’t have this major version ready by or
even sooner than the current yearly rhythm we have. In fact, if we do aim
to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
delay .NEXT…

Zeev

I'm not sure where the 2-3 years is coming from, but again, I see no
reason why we wouldn't be able to push .NEXT out within a year (if it's
just phpng along then actually a lot less, but I'm allowing time for extra
features we may want to put in). As a matter of fact, I don't think we
can even entertain a 2-3 cycle, it will be way too late to market if we
linger for so long.

We could make PHP NEXT in a year, sure, but it won’t be worthwhile being called PHP NEXT. There are a lot of big changes we can and should make and that would necessitate delaying it. Three years might be a bit long. However, I am confident that we need more than a year to make this major worth it.

This is the assumption we should take IMHO, and only branch 5.7 (and more
importantly, invest time in it) if it proves wrong.

Branching 5.7 wouldn’t be a big effort. Master is fairly stable, and if some RFCs pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT doesn’t happen next year (and I expect that it won’t), we’ll still have 5.7.

Andrea Faulds
http://ajf.me/

I'm not sure where the 2-3 years is coming from, but again, I see no
reason why we wouldn't be able to push .NEXT out within a year (if it's
just phpng along then actually a lot less, but I'm allowing time for extra
features we may want to put in). As a matter of fact, I don't think we
can even entertain a 2-3 cycle, it will be way too late to market if we
linger for so long.

This is the assumption we should take IMHO, and only branch 5.7 (and more
importantly, invest time in it) if it proves wrong.

This is the assumption we should not take. It is disturbing to see you
pushing again something so hard that it will hurt the whole project.
And this time much harder than in the last times.

It is time to step back and take a realistic view of what is going,
outside your book, which is barely based on your one and only
prioritiy, performance (and only one platform too). This is not PHP,
not what many want. And even I am pretty sure you will make it through
with this totally incomplete RFC based on disputable benchmarks and no
matter how much performance improvements happen with phpng, this is
not the only thing what we should do in next. Even if it was, to think
about being ready in less than a year is a sweet dream, to say it
nicely.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

The "the" before "start" is a mistake :)

Hi,

I didn't see any phpng related discussion for a day.
If we have nothing to discuss, may be we should just the start a voting
process. :)

It's not a problem for me to wait a week or even month. I just like to
know. if anyone thinks, that we have any stoppers to start the voting.

Last days we tried to improve https://wiki.php.net/phpng-upgrading
However, our English is poor and boring. It would be cool, if native
speakers would improve the docs. (section related to Objects is not ready
yet).

Thanks. Dmitry.

-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Wednesday, July 23, 2014 8:00 AM
To: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] RFC: Move phpng to master

I think before we do that we need to do much better documentation around
the changes in the engine. I know that in the past we followed the "code
is
documentation" pattern, but the code there becomes more and more dense,
with macros upon macros upon macros, and myriads of micro-optimizations
which make sense only in specific context. Absent that context and
documentation, understanding what is going on becomes much harder and so
becomes dealing with that code. Some of the changes right now are
partially
documented in https://wiki.php.net/phpng-int, some (like parameter
parsing
API) not documented at all. Given that, I'm not even sure I understand
what
phpng is right now - as I didn't have time to parse every commit during
active
development. So it would be nice to have some internal docs if we want
people to form an informed opinion about what is being proposed.

And, of course, the porting guide for extension authors is another
required
part. I know the phpng team did great work porting the extensions, but
people
would need to support them and add the new ones, so it is a must.

As Dmitry mentioned, this is something we're going to work on (with
primary
focus around the porting guide, and secondary focus on extending the
internals document).

Zeev

hi Dmitry,

Hi,

I didn't see any phpng related discussion for a day.
If we have nothing to discuss, may be we should just the start a voting
process. :)

It's not a problem for me to wait a week or even month. I just like to
know. if anyone thinks, that we have any stoppers to start the voting.

Last days we tried to improve https://wiki.php.net/phpng-upgrading
However, our English is poor and boring. It would be cool, if native
speakers would improve the docs. (section related to Objects is not ready
yet).

The current status of the doc, migration guide, list of changes and
explanation will force me to vote -1 at this point. I am very
reluctant to give you a blank card and then keep hearing "no" to every
2nd patch we will provide :)

Also none of my questions have been answered in the various phpng
threads, so it is not like I can vote +1 anyway...

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

Hi,

I didn't see any phpng related discussion for a day.
If we have nothing to discuss, may be we should just the start a voting
process. :)

It's not a problem for me to wait a week or even month. I just like to
know. if anyone thinks, that we have any stoppers to start the voting.

Last days we tried to improve https://wiki.php.net/phpng-upgrading
However, our English is poor and boring. It would be cool, if native
speakers would improve the docs. (section related to Objects is not ready
yet).

Our voting RFC prescribes that voting can start no earlier than two weeks
after the RFC announcement (which was three days ago). As this is a big
change and there's no particular rush to get this merged, I'd suggest to
stick with the usual process :)

Nikita

While this is a major change to the language implementation, it does
not actually affect end users in any meaningful way except for the positive
‘side effect’ of their apps running faster. So while we believe that
technically a 50%+1 vote should suffice, we hope to get well over 2/3.

If you're not going to delay this, then you should at very least clarify
the wording in this section. You believe 50%+1 should suffice but hope to
get well over 2/3. So is the required majority 50%+1 or 2/3?

The text I put there is exactly what I think about the subject of required
majority. 50%+1 is enough for a change that does not effect end users in
any meaningful way, but I'll be happier if it received a 2/3 majority to
leave any doubts away.

It affects users, it is a total rewamp of the engine, it requires 2/3.
I fail to understand to see yet another attempt to discard simple RFC
rules.

I should also point out that, according to the Voting RFC, whether or not

an RFC "actually affects end users in any meaningful way" is NOT a factor
in determining whether a 2/3 supermajority is required or not. Here's what
it actually states:

For these reasons, a feature affecting the language itself (new syntax
for example) will be considered as 'accepted' if it wins a 2/3 of the
votes. Other RFCs require 50% + 1 votes to get 'accepted'.

Since the phpng RFC already acknowledges that it affects the language
itself, this is clearly a 2/3 requirement situation. Whether it affects
end-users or not is irrelevant. Under current rules, your RFC must have
2/3 support in order to pass.

As the person who wrote that text in the Voting RFC, I can tell you with
absolute certainty that you are 100% wrong in your interpretation, as I've
said numerous times in the past.
A feature that affects the language itself is not a feature that affects
the language implementation.

It affects both, there is no point to argue.

I updated the section to be fully technical and removed my wish of heart to
get a 2/3 majority. Although I'd still very much like to get > 2/3, it's
not required.

It is.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

2014.07.25. 9:52, "Zeev Suraski" zeev@zend.com ezt írta:

While this is a major change to the language implementation, it does
not actually affect end users in any meaningful way except for the
positive
‘side effect’ of their apps running faster. So while we believe that
technically a 50%+1 vote should suffice, we hope to get well over 2/3.

If you're not going to delay this, then you should at very least clarify
the wording in this section. You believe 50%+1 should suffice but hope
to
get well over 2/3. So is the required majority 50%+1 or 2/3?

The text I put there is exactly what I think about the subject of required
majority. 50%+1 is enough for a change that does not effect end users in
any meaningful way, but I'll be happier if it received a 2/3 majority to
leave any doubts away.

I should also point out that, according to the Voting RFC, whether or not

an RFC "actually affects end users in any meaningful way" is NOT a
factor
in determining whether a 2/3 supermajority is required or not. Here's
what
it actually states:

For these reasons, a feature affecting the language itself (new syntax
for example) will be considered as 'accepted' if it wins a 2/3 of the
votes. Other RFCs require 50% + 1 votes to get 'accepted'.

Since the phpng RFC already acknowledges that it affects the language
itself, this is clearly a 2/3 requirement situation. Whether it affects
end-users or not is irrelevant. Under current rules, your RFC must have
2/3 support in order to pass.

As the person who wrote that text in the Voting RFC, I can tell you with
absolute certainty that you are 100% wrong in your interpretation, as I've
said numerous times in the past.
A feature that affects the language itself is not a feature that affects
the language implementation.

hi,

I'm not really following the phpng development that closely, but afaik it
does have some userland impact (the change for using the same argument name
in a function signature multiple times and the change in func_get_args()
comes into mind).

We also discussed before that major breakage in the extension "api" would
also warrant a 2/3 vote, but it seems that you disagree with that.

My last argument is, that given that we allow anybody with a php.net
account to vote on Zend Engine changes, we are always safer with the 2/3
vote.
That way the worst thing that can happen is something not getting into, but
the authors can try again (after fixing the cause of the no votes), but
with simple majority it would be rather easy to force something into the
language, even if all of the active Zend maintainers vote no because it is
a horrible design decision or has a crappy implementation.

just my 2 cents ofc.

While this is a major change to the language implementation, it does
not actually affect end users in any meaningful way except for the positive
‘side effect’ of their apps running faster. So while we believe that
technically a 50%+1 vote should suffice, we hope to get well over 2/3.

If you're not going to delay this, then you should at very least clarify
the wording in this section. You believe 50%+1 should suffice but hope to
get well over 2/3. So is the required majority 50%+1 or 2/3?

The text I put there is exactly what I think about the subject of required
majority. 50%+1 is enough for a change that does not effect end users in
any meaningful way, but I'll be happier if it received a 2/3 majority to
leave any doubts away.

I should also point out that, according to the Voting RFC, whether or not

an RFC "actually affects end users in any meaningful way" is NOT a factor
in determining whether a 2/3 supermajority is required or not. Here's what
it actually states:

For these reasons, a feature affecting the language itself (new syntax
for example) will be considered as 'accepted' if it wins a 2/3 of the
votes. Other RFCs require 50% + 1 votes to get 'accepted'.

Since the phpng RFC already acknowledges that it affects the language
itself, this is clearly a 2/3 requirement situation. Whether it affects
end-users or not is irrelevant. Under current rules, your RFC must have
2/3 support in order to pass.

As the person who wrote that text in the Voting RFC, I can tell you with
absolute certainty that you are 100% wrong in your interpretation, as I've
said numerous times in the past.
A feature that affects the language itself is not a feature that
affects the language implementation.

That may be what you meant, Zeev, but that's not what you wrote. As Jonny
already pointed out, what you intended isn't relevant if it doesn't match
the final wording you actually put in there.

The Voting RFC doesn't say "language implementation". It says "language".
That means, if it affects the language, it requires 2/3. Period. If you
wanted it to have a more narrow definition, then why didn't you put it in
there? It's just not making any sense to me. You might want to consider
putting an amendment to the Voting RFC to a vote to clarify that language,
but as it stands right now, any feature that affects the language itself--
regardless of userland impact-- requires a 2/3 vote. Saying, "Well, that's
not exactly what I meant," after the fact just isn't a convincing argument
for me.

Generally speaking, now that we have a Specification project, the spirit
of the Voting RFC is that changes to the Language Specification would
require 2/3 majority, while all other changes would not. This is also not
100% accurate since there are some elements of the language behavior that
aren't covered by the spec (e.g.superglobal availability and behavior) -

Again, I'd strongly suggest you propose new language for the Voting RFC to
reflect these statements, because none of that is apparent in the current
wording.

but replacing the implementation with a compatible one absolutely does
not fall within the realm of "features that affect the language".

I disagree. Whether or not the new stuff is "compatible", it does directly
affect the language. The PHPNG RFC itself even acknowledges that it
affects the language. Furthermore, as far as the "spirit" of the Voting
RFC is concerned, I seriously doubt it would be in the spirit of it to
merge a massive overhaul of the codebase that will affect virtually all
development with just a simple majority. It could be (and has been) argued
that this will inevitably lead to userland changes. But again, whether it
affects userland or not is completely irrelevant. The Voting RFC says--
whether you "meant" it to or not, it does say-- that 2/3 is required if it
affects the language, period. It does not contain any exceptions for
lessened impact on userland.

If you recall the 64-bit discussion several months ago, when I was (back
then) on the opposing side, I clearly said to people who said this requires
a 2/3 majority that it's very debatable - because while it does have some
end user impact that changes the language behavior, it's mostly an
implementation issue, which as such requires a simple majority. So I'm
both consistent, and not reinterpreting the rules to fit my needs.

Fair enough. You have been consistent on this so I don't think anyone can
reasonably accuse you of just trying to twist this to suit your needs.

As such, I ask that you at least update the wording to make it clear that

2/3 is required for the RFC to pass in order to avoid confusion when it
comes to a vote. I still think you should hold-off until these other
issues of dispute are resolved, though. But that's your choice. I simply
ask that you fix the required majority section to make it in compliance
with current voting rules.

I updated the section to be fully technical and removed my wish of heart
to get a 2/3 majority. Although I'd still very much like to get > 2/3,
it's not required.

According to the current Voting RFC rules, this RFC must require a 2/3
majority because it affects the language. Ugh this is exactly why an
adjudication process is needed, which we don't have that I'm aware of. We
don't have a "supreme court" to decide this. But it's clear that we need
some way to adjudicate this in a manner that would be acceptable to both
sides. The alternative is for you and everyone else to keep repeating
their arguments back and forth. Then, if your RFC gets a simple majority
but not 2/3, we can watch as you try to carry out the merge and Pierre and
whoever else try to block and revert it. I don't think that's an ideal
outcome but that is where we're headed. Even if you believe you're
justified in using this interpretation that expands the stated meaning, I
really think you should go with the 2/3 vote in order to avoid sparking
what could be a very ugly conflict.

Please take the high road on this, then later we can revisit the Voting RFC
and discuss collectively how to make it clearer for situations like this.

--Kris

Hi Zeev,

Now we're into arguing semantics of the Voting RFC. Whether you meant
something else when you wrote that is now irrelevant, it's what is written
that is the rule, not somebodies individual interpretation surely? "In any
meaning full way" are your words, not what the accepted RFC states.

From what's been said previously, the changes in NG are strictly
implementation changes, i.e. syntax etc remains the same throughout. That's
great, and would require a 50%+1 for vote as far as I can see.

However.

If there are /any/ changes to what end-users would see, that is by
definition a change in the language, no matter how small (or
"meaningless"), you are into 2/3 majority territory.

So, can those who have worked on it confirm with a simple yes / no, are
there changes (right now) that may affect users. Second, if the answer is
"no", is there somebody that can review and confirm that this is the case
that hasn't worked on NG preferably (not because of trust, just because
it's a large changeset which makes it easy to miss stuff and a fresh pair
of eyes is good).

Now. If yes, 2/3 majority is required. It's as simple as that. If no, then
I would suggest starting the review to confirm. I would hope that the
remaining time in the 2 weeks would be enough to accomplish a review, but
somebody correct me if they think otherwise, so the vote start / end should
hopefully be unaffected beyond vote requirements.

Cheers.
Jonny.