[PHP-DEV] Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread David Dai
> 
> 
> On 27 07 2014, at 11:44, Kris Craig  (mailto:kris.cr...@gmail.com)> wrote:
> 
> [a lot]
> 
> Maybe because you see those as competitors, but I see HHVM and friends as 
> current competitors, being evaluated to replace stock PHP, which is 
> definitely not covered by any nice statistics you can currently view.
> 
I can confirm that,  wikimedia is migrating from PHP to HHVM, see:  
http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html
and I also have saw many friends talking about migrating from PHP to HHVM only 
for performance gain. 
> 
> Cheers,
> Mike
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php



Cheers,
David Dai

  



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Mike Willbanks
First off, I realize I am top posting but this thread is becoming extremely
off-topic, unbalanced and overall ridiculous to see from the sidelines as
someone that contributes to open source and also utilizes PHP on a daily
basis for more than the last decade.

Seriously, cut the shit!  Everyone is bringing this to a personal and
completely insane area; let's focus on the facts not the reactions wherever
they might come from.  Work together, no one ever agrees 100% of the time
and continuing on that note, no one makes the best choices 100% of the
time.  Surely, as a community we will not always agree on implementations,
timing and what is done in "secret" vs. not, what is more maintainable vs.
what is not.  Where to dedicate focus etc.  Open source projects often have
this issue.  Also, no I am not taking a stance or side on what is best for
the language.  People contributing to the engine are much smarter than I in
this level and the right choice I am certain will prevail.  But have a
reasonable conversations on facts vs. personal opinions and vendettas.

Now, PHP is a balanced language; performance comes with a cost if it be
memory, CPU spikes, maintainability, readability, etc.   We all program
here; this is always a trade off we need to determine, analyze and
identify.  These things have to be taken into account.  Documentation is
nice but not always necessary.  Depending on what it will change and how
much affect it will have on say extension developers and existing people
contributing to core has to be taken into account.

Let's get our heads straight, determine our focus for the next few years
and start to move forward.  Sure other languages gain and lose on PHP but
this will always be the case and should not be the core focus; we're not a
company that's on the stock market.  Languages will evolve, change, become
invented but it's not like PHP is going away in a rapid decline; sure there
is more languages and more competition out there.  For instance, I have
been writing node.js lately and find a massive benefit in certain types of
projects; it comes to utilizing the right tool for the right job.  Surely
you are not going to attempt to write PHP for something that should be done
in assembly or visa-versa.  Market share does affect our jobs and careers
but there is a reason the language has been successful and will continue to
be.  A speed increase is not a magical bullet here, if that was the case
and they wanted to use PHP they'd use HHVM or even Hack lang and change
their usage.  (Yes, there are other things there but come on, 99% of the
time core PHP speed is not the issue.)

Let's save the effort on this useless conversation, focus on driving
SOMETHING forward, WHATEVER that may be and stop taking everything so damn
personal.

Regards,

Mike


On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig  wrote:

> On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki  wrote:
>
> > Hi all,
> >
> > On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner  >
> > wrote:
> >
> >>
> >> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> >> mike.php@gmail.com> wrote:
> >> >>
> >> >>
> >> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >> >
> >> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >> >
> >> >>
> >> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >> >
> >> > Umm, how?  Do you have any data to support this?  According to
> >> http://php.net/usage.php, as of 2012, PHP's usage is steadily
> >> increasing.  As far as our competitors are concerned, well:
> >> >
> >> >
> >>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >> >
> >> >
> >> > As you can see, PHP continues to dominate with over 80% market share
> >> and no signs-- at least, none that I can see-- that we are "losing
> ground"
> >> as you stated.
> >> >
> >>
> >> Surely it's wise to make the same wrong assumptions Microsoft did with
> >> Internet Explorer?
> >>
> > PHP is losing as a general scripting language for sure.
> > JavaScript is winning in this area even if it was originated as "a web
> > client scripting language".
> >
> > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> > http://langpop.com/
> >
> > We are better to consider this situation seriously. IMHO.
> > Focus on web as well as encourage general usage is what we need.
> > Making PHP a choice for "new" project should be one of the most important
> > objective.
> >
> > Regards,
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> >
> According to w3techs, JavaScript retains an extremely tiny market share in
> terms of general purpose languages:
>
>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
>
>
> It looks like the sources are all measuring different metrics.  It would be
> interesting to see a closer analysis of the data and figure out which
> metrics are the most relevant to 

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Yasuo Ohgaki
Hi Kris,

On Mon, Jul 28, 2014 at 9:18 AM, Kris Craig  wrote:

> According to w3techs, JavaScript retains an extremely tiny market share in
> terms of general purpose languages:
>
>
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
>
>
> It looks like the sources are all measuring different metrics.  It would
> be interesting to see a closer analysis of the data and figure out which
> metrics are the most relevant to this question.
>

Since we have enough market share on web apps already, why don't we focus
more on developers? There are many awesome none web app tools that are
developed with JavaScript because of it's popularity and developers'
passion.

PHP is losing popularity for sure.

http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.html

PHP is the worst in terms of lost popularity among top 20 languages. It
should be
a flag for us to adjust our strategy/view. Market share comes after
language popularity.
When market share has changed, it would be too late.

Anyway, I'm willing to have phpng as master, as well as INT64 branch.
Both are good for PHP. IMO.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Kris Craig
On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner 
> wrote:
>
>>
>> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
>> >
>> >
>> >
>> >
>> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
>> mike.php@gmail.com> wrote:
>> >>
>> >>
>> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>> >> >
>> >> > Here's my question to counter yours, Michael:  What's the rush?
>> >> >
>> >>
>> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
>> >
>> > Umm, how?  Do you have any data to support this?  According to
>> http://php.net/usage.php, as of 2012, PHP's usage is steadily
>> increasing.  As far as our competitors are concerned, well:
>> >
>> >
>> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
>> >
>> >
>> > As you can see, PHP continues to dominate with over 80% market share
>> and no signs-- at least, none that I can see-- that we are "losing ground"
>> as you stated.
>> >
>>
>> Surely it's wise to make the same wrong assumptions Microsoft did with
>> Internet Explorer?
>>
> PHP is losing as a general scripting language for sure.
> JavaScript is winning in this area even if it was originated as "a web
> client scripting language".
>
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> http://langpop.com/
>
> We are better to consider this situation seriously. IMHO.
> Focus on web as well as encourage general usage is what we need.
> Making PHP a choice for "new" project should be one of the most important
> objective.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
According to w3techs, JavaScript retains an extremely tiny market share in
terms of general purpose languages:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


It looks like the sources are all measuring different metrics.  It would be
interesting to see a closer analysis of the data and figure out which
metrics are the most relevant to this question.

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Kris Craig
On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner 
wrote:

>
> On 27 07 2014, at 11:44, Kris Craig  wrote:
>
> [a lot]
>
> Maybe because you see those as competitors,


You're the one who said PHP was losing ground to its "competitors", not I.

but I see HHVM and friends as current competitors, being evaluated to
> replace stock PHP, which is definitely not covered by any nice statistics
> you can currently view.
>

So, in other words, you're basing your claim on anecdotal and purely
hypothetical assumptions about unnamed people "evaluating" other languages
to replace PHP.  Even if your self-serving guess were true, for which there
is no evidence that has been presented here, it still wouldn't substantiate
your claim because evaluating alternatives to your current codebase doesn't
mean you're going to actually switch to any of them.  So either way, PHP is
not, as you claimed, "losing ground" to anyone.

[a lot]
>

I've been trying to maintain a civil discussion here, but I have to say,
Michael, thus far you have done nothing but make immature, snyde personal
attacks and baseless, factually inaccurate claims.  You have not
contributed anything substantive or constructive to this debate up to this
point.  From your "rolling eyes" comment where you speculated about your
dog wanting voting rights to now, you have been very disrespectful and
uncivil toward everyone here.  I don't want to discourage anyone from
expressing their views, but on the same token, I'm not here to feed trolls.

This issue clearly brings out strong emotions in some people and we clearly
disagree on certain points.  That said, please make a greater effort to be
respectful toward other people on this list, whether you agree with them or
not.  Your trolling comments have all but hijacked this thread over the
last 17 hours and it's detracting from substantive debate that needs to
happen.

If you have some issue with me personally, please take it off-list.  If
you're going to post further on this thread, please try to be more
respectful and mature in your comments.

--Kris


http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Yasuo Ohgaki
Hi all,

On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >
> >
> >
> >
> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> mike.php@gmail.com> wrote:
> >>
> >>
> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >
> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >
> >>
> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >
> > Umm, how?  Do you have any data to support this?  According to
> http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
>  As far as our competitors are concerned, well:
> >
> >
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >
> >
> > As you can see, PHP continues to dominate with over 80% market share and
> no signs-- at least, none that I can see-- that we are "losing ground" as
> you stated.
> >
>
> Surely it's wise to make the same wrong assumptions Microsoft did with
> Internet Explorer?
>
PHP is losing as a general scripting language for sure.
JavaScript is winning in this area even if it was originated as "a web
client scripting language".

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/

We are better to consider this situation seriously. IMHO.
Focus on web as well as encourage general usage is what we need.
Making PHP a choice for "new" project should be one of the most important
objective.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Kristopher
Instead of endless, useless bickering, how about everyone both for and
against merging jump in and start helping with phpng (docs, api
cleanup/stabilization, but fixes, etc)?

Imagine how much more stable and ready to merge it would be if you
concentrated the saber rattling energy towards actually accomplishing
something.




On Sun, Jul 27, 2014 at 6:00 AM, Michael Wallner 
wrote:

>
> On 27 07 2014, at 11:44, Kris Craig  wrote:
>
> [a lot]
>
> Maybe because you see those as competitors, but I see HHVM and friends as
> current competitors, being evaluated to replace stock PHP, which is
> definitely not covered by any nice statistics you can currently view.
>
> Cheers,
> Mike
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Michael Wallner

On 27 07 2014, at 11:44, Kris Craig  wrote:

[a lot]

Maybe because you see those as competitors, but I see HHVM and friends as 
current competitors, being evaluated to replace stock PHP, which is definitely 
not covered by any nice statistics you can currently view.

Cheers,
Mike


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Kris Craig
On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 09:26, "Kris Craig"  wrote:
> >
> >
> >
> >
> > On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
> mike.php@gmail.com> wrote:
> >>
> >>
> >> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >> >
> >> > Here's my question to counter yours, Michael:  What's the rush?
> >> >
> >>
> >> Every day php-ng is not GA, PHP is losing ground to its competitors.
> >
> > Umm, how?  Do you have any data to support this?  According to
> http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
>  As far as our competitors are concerned, well:
> >
> >
> http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
> >
> >
> > As you can see, PHP continues to dominate with over 80% market share and
> no signs-- at least, none that I can see-- that we are "losing ground" as
> you stated.
> >
>
> Surely it's wise to make the same wrong assumptions Microsoft did with
> Internet Explorer?
>
Again, where's your evidence, Michael?  I provided two separate sources
that provide data showing that PHP is *gaining* market share and continues
to dominate over the competition, which directly contradicts the claim you
made.  Simply brushing this factual data as "wrong assumptions"-- without
any data of your own to back-up that claim-- does not constitute a valid
counter-argument, nor does introducing a non sequitur by comparing PHP to
Internet Explorer.

These aren't "assumptions", wrong or otherwise.  This is data pulled from
reliable sources.  If you have separate data that calls it into question,
then please share it with us.  Otherwise, you're just making baseless and
factually inaccurate claims about PHP to justify your argument about
PHP-NG.  As far as I can tell from the evidence available, your statement
that "PHP is losing ground to its competitors" appears to be false.  In
fact, the exact opposite appears to be true.  Again, that's not an
assumption.  That's just looking at the available data.

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Michael Wallner
On 27 Jul 2014 09:26, "Kris Craig"  wrote:
>
>
>
>
> On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
wrote:
>>
>>
>> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>> >
>> > Here's my question to counter yours, Michael:  What's the rush?
>> >
>>
>> Every day php-ng is not GA, PHP is losing ground to its competitors.
>
> Umm, how?  Do you have any data to support this?  According to
http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
 As far as our competitors are concerned, well:
>
>
http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
>
>
> As you can see, PHP continues to dominate with over 80% market share and
no signs-- at least, none that I can see-- that we are "losing ground" as
you stated.
>

Surely it's wise to make the same wrong assumptions Microsoft did with
Internet Explorer?


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Lester Caine
On 27/07/14 08:26, Kris Craig wrote:
> As you can see, PHP continues to dominate with over 80% market share and no
> signs-- at least, none that I can see-- that we are "losing ground" as you
> stated.
> 
> So again:  What's the rush?

Especially since 75% of that are still on PHP5.3 or 5.2 ;)

But I had forgotten the comparison has a breakdown by ranking. I made
the unsubstantiated comment about big sites not using PHP which of cause
this shows, but there is no reference to the alternative PHP engines?
One question that does come too mind is "Why is python so popular with
the bigger sites?" Is it because compiled builds are fully supported?
Certainly if any of my own sites traffic started to take off I would be
looking down that avenue, so while improving the speed of interpreted
working is important, it is still stability in the language that blocks
uptake?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Lester Caine
On 27/07/14 07:23, Kris Craig wrote:
> Here's my question to counter yours, Michael:  What's the rush?

I think that the only 'objection' I have to 'simply' merging phpng is
that it is not just a 'single' change? This vote is all or nothing, so
every change is bundled without a vote on particular elements. That many
elements ARE simply improvements to the speed at which things   are
processed is not the problem here, and it may well be that the changes
that do affect BC have a practical justification, but there will not be
a discussion on that?

I'm currently fighting a problem due to a blanket change to a number of
systems, which offer a vast speed improvement, but now apparently make
it impossible to identify the location of the client machine. The change
to VDI is a done deal but nobody on site seems to be interested in
fixing the resulting problem :( Due diligence would have addressed the
problem beforehand and could well have steered things a different way.

The 'rush' with phpng is that people need to have a stable base to be
working with, and if php-next is to be phpng, then we need to be working
with it. If I magically found some spare time today should I be looking
at the current code base or phpng going forward? Documentation IS
crucial here, and documenting those changes and providing information
where an individual change affects BC  is essential, but there should be
some mechanism to review elements that are not so clear cut? IS_BOOL
object container against IS_TRUE and IS_FALSE new values is probably not
a good example, but it is a change that I don't currently see full
rational behind ... if I create a bool container I don't know which
value it is ...

We do not want to complicate things by voting on each element, but it's
the simple fact that so many elements have been re-engineered without
the normal process that is causing irritation, so some agreement that if
questions are raised about an element then it WILL get a proper
discussion and if justified get reverted? I think that this is part of
the debate on 2/3rds or 50-50 ... there are elements which would
normally be a 2/3rds decision? So there should be an agreement that
these can be reviewed again later?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Kris Craig
On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
wrote:

>
> On 27 Jul 2014 08:23, "Kris Craig"  wrote:
> >
> > Here's my question to counter yours, Michael:  What's the rush?
> >
>
> Every day php-ng is not GA, PHP is losing ground to its competitors.
>
Umm, how?  Do you have any data to support this?  According to
http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
 As far as our competitors are concerned, well:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python


As you can see, PHP continues to dominate with over 80% market share and no
signs-- at least, none that I can see-- that we are "losing ground" as you
stated.

So again:  What's the rush?

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-27 Thread Michael Wallner
On 27 Jul 2014 08:23, "Kris Craig"  wrote:
>
> Here's my question to counter yours, Michael:  What's the rush?
>

Every day php-ng is not GA, PHP is losing ground to its competitors.

People seem to ignore this because of cosmetics.


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Pierre Joye
On Sun, Jul 27, 2014 at 8:10 AM, Michael Wallner  wrote:
>
> On 27 07 2014, at 02:53, Kris Craig  wrote:
>>
>> So even IF you want to reduce the scope of the 2/3 requirement to language
>> impacts in userland only, your RFC *still* falls under that requirement
>> because it directly affects the language itself in userland, as described
>> above.  I would again invite you to reconsider your position on this and
>> avoid a protracted fight on this that would only serve to split the
>> community.
>
>
> I’m actually not sure why we even have to vote on PHP-NG?

As it is surely a rhetoric question, let leave it, ok?

> How about for the crusaders to build something comparable to put up to vote 
> against PHP-NG?
>
> There isn’t? Well, then let’s go ahead. Simple.
>
> Rolling eyes,
> Mike
>
>
> PS: My dog wants voting rights because he feels like he’ll be affected by 
> changes to PHP.

This kind of post surely brings us a huge step forward.


Cheers,
-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Kris Craig
On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner 
wrote:

>
> On 27 07 2014, at 02:53, Kris Craig  wrote:
> >
> > So even IF you want to reduce the scope of the 2/3 requirement to
> language
> > impacts in userland only, your RFC *still* falls under that requirement
> > because it directly affects the language itself in userland, as described
> > above.  I would again invite you to reconsider your position on this and
> > avoid a protracted fight on this that would only serve to split the
> > community.
>
>
> I’m actually not sure why we even have to vote on PHP-NG?
>
> How about for the crusaders to build something comparable to put up to
> vote against PHP-NG?
>
> There isn’t? Well, then let’s go ahead. Simple.
>

To answer your question (sort-of), the alternative to PHP-NG is what we
have right now.  I can't speak for anyone else, of course, but I certainly
am not opposed to PHP-NG, even though Zeev seems to think so.  I just don't
think it's ready to be merged into master yet, based on everything I've
seen, including concerns raised by others more knowledgeable than I on this
list.  I also just want to make sure something so massive in scope isn't
pushed through by a slim majority, especially since doing so would violate
the Voting RFC as it's currently written and would probably lead to an ugly
fight among those who have RW+ access.

I actually like PHP-NG and what it strives to do.  I just think its
developers are jumping the gun and trying to force something through that
many in the community feel is not yet ready for deployment.  I honestly
don't understand why there's such a rush and why people who are calling for
things to slow down so that cooler heads can prevail are being demonized
and mocked.  It's not "you're either with us or you're against us."  I
don't oppose PHP-NG simply because I want to make sure all the ducks are in
a row before it's deployed.

Here's my question to counter yours, Michael:  What's the rush?

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Michael Wallner

On 27 07 2014, at 02:53, Kris Craig  wrote:
> 
> So even IF you want to reduce the scope of the 2/3 requirement to language
> impacts in userland only, your RFC *still* falls under that requirement
> because it directly affects the language itself in userland, as described
> above.  I would again invite you to reconsider your position on this and
> avoid a protracted fight on this that would only serve to split the
> community.


I’m actually not sure why we even have to vote on PHP-NG?

How about for the crusaders to build something comparable to put up to vote 
against PHP-NG?

There isn’t? Well, then let’s go ahead. Simple.

Rolling eyes,
Mike


PS: My dog wants voting rights because he feels like he’ll be affected by 
changes to PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Andrea Faulds

On 27 Jul 2014, at 01:53, Kris Craig  wrote:

> so func_get_arg() and func_get_args() will return current value of argument
> instead of the actually passed. The following code is going to be affected
> “function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”

Those are to be considered functions, not language features.

>> 
>> Function parameters with duplicate name are not allowed anymore.
> Definitions like “function foo($x,$x) {}” will lead to compile time error
> “Redefinition of parameter”

While that’s *technically* a language change, such code doesn’t work properly 
anyway.

--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Kris Craig
On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski  wrote:

> Kris,
>
>
>
> I’ll make it short.
>
>
>
> EVERY RFC affects the language in *some* way – be it its features,
> positioning, perception, performance, implementation, testability, you name
> it.
>

I believe that argument is specious.  The RFC says, "a feature
affecting the language *itself*" (emphasis mine).  A feature that affects
performance need not necessarily affect the language itself.  For example,
an RFC to add an APXS configuration option to the configure script would
have no impact on the language itself, even though it technically involves
a modified implementation and testing scenario.  And affecting people's
"perception" of PHP most certainly does not constitute a feature that
affects the language itself, unless you're making a quantum theory argument
wherein the mere act of observing something alters its state.

Finally, here's an example from your RFC of how it *directly* impacts the
language itself:

> PHPNG doesn't keep original values of arguments passed to user functions,
so func_get_arg() and func_get_args() will return current value of argument
instead of the actually passed. The following code is going to be affected
“function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
>
> Function parameters with duplicate name are not allowed anymore.
Definitions like “function foo($x,$x) {}” will lead to compile time error
“Redefinition of parameter”

So even IF you want to reduce the scope of the 2/3 requirement to language
impacts in userland only, your RFC *still* falls under that requirement
because it directly affects the language itself in userland, as described
above.  I would again invite you to reconsider your position on this and
avoid a protracted fight on this that would only serve to split the
community.

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Matteo Beccati
On 27/07/2014 00:32, Andrea Faulds wrote:
>> Is PHPNG a feature?  No, it’s not.  It’s improvements & performance
>> optimizations at the implementation level.  Those who have been following
>> my involvement on internals@ over the years know my position about both
>> feature creep and downwards compatibility, and I’m absolutely certain that
>> it was clear to them – most if not all – what the meaning here was.  That’s
>> 100.0% irrelevant to PHPNG.
> 
> For what it’s worth, I’d completely agree with Zeev here. phpng is really 
> just an implementation deal, it doesn’t need a 2/3 vote, controversial or no.

I agree about the meaning and the fact that phpng is implementation.

However if there is some userland BC break, then it should effectively
be 2/3, shouldn't it? How about the "Incompatibilities (made on purpose
and are not going to be fixed)"?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Benjamin Eberlei
In that case tthe voting RFC should be improved. The sentence about 1/2 vs
2/3 votes is really ambiguous.
Not fixing it will always lead to discussions over and over again.


On Sun, Jul 27, 2014 at 12:32 AM, Andrea Faulds  wrote:

>
> On 26 Jul 2014, at 23:16, Zeev Suraski  wrote:
>
> > *“**Given that changes to languages (as opposed to changes to apps or
> even
> > frameworks) are for the most part irreversible”*
> >
> >
> >
> > Implementation improvements such as PHPNG are not irreversible.  New
> > features or changed features are.  This deals with language features,
> that
> > once we publish, we cannot take back as people already start using them.
> >
> >
> >
> > *“the purpose of the vote is to ensure that there's strong support for
> the
> > proposed feature.”*
> >
> >
> >
> > Is PHPNG a feature?  No, it’s not.  It’s improvements & performance
> > optimizations at the implementation level.  Those who have been following
> > my involvement on internals@ over the years know my position about both
> > feature creep and downwards compatibility, and I’m absolutely certain
> that
> > it was clear to them – most if not all – what the meaning here was.
>  That’s
> > 100.0% irrelevant to PHPNG.
>
> For what it’s worth, I’d completely agree with Zeev here. phpng is really
> just an implementation deal, it doesn’t need a 2/3 vote, controversial or
> no.
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Andrea Faulds

On 26 Jul 2014, at 23:16, Zeev Suraski  wrote:

> *“**Given that changes to languages (as opposed to changes to apps or even
> frameworks) are for the most part irreversible”*
> 
> 
> 
> Implementation improvements such as PHPNG are not irreversible.  New
> features or changed features are.  This deals with language features, that
> once we publish, we cannot take back as people already start using them.
> 
> 
> 
> *“the purpose of the vote is to ensure that there's strong support for the
> proposed feature.”*
> 
> 
> 
> Is PHPNG a feature?  No, it’s not.  It’s improvements & performance
> optimizations at the implementation level.  Those who have been following
> my involvement on internals@ over the years know my position about both
> feature creep and downwards compatibility, and I’m absolutely certain that
> it was clear to them – most if not all – what the meaning here was.  That’s
> 100.0% irrelevant to PHPNG.

For what it’s worth, I’d completely agree with Zeev here. phpng is really just 
an implementation deal, it doesn’t need a 2/3 vote, controversial or no.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Zeev Suraski
Kris,



I’ll make it short.



EVERY RFC affects the language in *some* way – be it its features,
positioning, perception, performance, implementation, testability, you name
it.  Each and every one, or we wouldn’t be discussing it on php.net’s
internals@ mailing list.  So I’m afraid I’m not going to use *your*
interpretation for what the Voting RFC means (which in effect is either 2/3
majority for every RFC) – but rather, what I *know* is the meaning, and
what is clearly the spirit of the RFC.  Spirit I say?  Here’s what I mean:



*“**Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible”*



Implementation improvements such as PHPNG are not irreversible.  New
features or changed features are.  This deals with language features, that
once we publish, we cannot take back as people already start using them.



*“the purpose of the vote is to ensure that there's strong support for the
proposed feature.”*



Is PHPNG a feature?  No, it’s not.  It’s improvements & performance
optimizations at the implementation level.  Those who have been following
my involvement on internals@ over the years know my position about both
feature creep and downwards compatibility, and I’m absolutely certain that
it was clear to them – most if not all – what the meaning here was.  That’s
100.0% irrelevant to PHPNG.


FYI, I don’t intend to ping pong with you about it.  I’ve said what I had
to say about that topic.



Zeev


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-26 Thread Kris Craig
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski  wrote:

>
>
>
> On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig  wrote:
>
>>
>>
>> > 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 unti

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Jonny Stirling
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.


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Ferenc Kovacs
2014.07.25. 9:52, "Zeev Suraski"  ezt írta:
>
> On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig  wrote:
>
> >
> >
> > > 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.


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Pierre Joye
On Fri, Jul 25, 2014 at 9:51 AM, Zeev Suraski  wrote:
> On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig  wrote:
>
>>
>>
>> > 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Zeev Suraski
Maybe we should wait to see if PHP 7 gets chosen and jump to
ZEND_ENGINE_4?   J

Another option would be to simply align the version number with that of
PHP.  The separate version number dates back to 1999 where we thought we
may put this language engine into projects other than PHP, but I think it’s
safe to say that if we didn’t get around to it until now, it’s probably not
going to happen in the future…



BTW, the only reason it’s 2.7 is because the PHP version there is presently
5.7.

Zeev



*From:* Dmitry Stogov [mailto:dmi...@zend.com]
*Sent:* Friday, July 25, 2014 10:23 AM
*To:* Yasuo Ohgaki
*Cc:* Zeev Suraski; PHP internals
*Subject:* Re: [PHP-DEV] RFC: Move phpng to master



We didn't care about versions while it was a separate branch.

Changing to ZEND_ENGINE_3 makes full sense from my point of view.

Thanks. Dmitry.



On Fri, Jul 25, 2014 at 7:47 AM, Yasuo Ohgaki  wrote:

Hi Zeev,

On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski  wrote:

> The RFC is available at https://wiki.php.net/rfc/phpng
>
>
>
> Some supporting links available down below.
>
>
>
> Comments welcome!
>

It says Zend2 in zend.h

25 #define ZEND_VERSION "2.7.0-dev"
26
27 #define ZEND_ENGINE_2

Isn't it better named Zend3?
It may be changed anytime, though.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Zeev Suraski
On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig  wrote:

>
>
> > 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*.
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) - but
replacing the implementation with a compatible one absolutely does *not* fall
within the realm of "features that affect the language".

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.

 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.

Zeev


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-25 Thread Dmitry Stogov
We didn't care about versions while it was a separate branch.

Changing to ZEND_ENGINE_3 makes full sense from my point of view.

Thanks. Dmitry.


On Fri, Jul 25, 2014 at 7:47 AM, Yasuo Ohgaki  wrote:

> Hi Zeev,
>
> On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski  wrote:
>
> > The RFC is available at https://wiki.php.net/rfc/phpng
> >
> >
> >
> > Some supporting links available down below.
> >
> >
> >
> > Comments welcome!
> >
>
> It says Zend2 in zend.h
>
> 25 #define ZEND_VERSION "2.7.0-dev"
> 26
> 27 #define ZEND_ENGINE_2
>
> Isn't it better named Zend3?
> It may be changed anytime, though.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Pierre Joye
On Fri, Jul 25, 2014 at 6:28 AM, Kris Craig  wrote:

>> 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.

2/3 is required, there is no doubt about it.

That being said, I think we should block this RFC as it is by far one
of the poorest one from a content point of view (referring to the RFC
itself here). phpng is a huge change, or better said a huge set of
huge changes. Even the php-next version number RFC has more details
that this one.  This is disturbing.

The various document should be linked or merged (docs relevant
directly to this rfc should be merged, link to
https://wiki.php.net/phpng-upgrading is missing too. I can help with
these steps next week.

Cheers,
-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Kris Craig
On Thu, Jul 24, 2014 at 8:47 PM, Yasuo Ohgaki  wrote:

> Hi Zeev,
>
> On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski  wrote:
>
> > The RFC is available at https://wiki.php.net/rfc/phpng
> >
> >
> >
> > Some supporting links available down below.
> >
> >
> >
> > Comments welcome!
> >
>

> 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?

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 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.

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Yasuo Ohgaki
Hi Zeev,

On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski  wrote:

> The RFC is available at https://wiki.php.net/rfc/phpng
>
>
>
> Some supporting links available down below.
>
>
>
> Comments welcome!
>

It says Zend2 in zend.h

25 #define ZEND_VERSION "2.7.0-dev"
26
27 #define ZEND_ENGINE_2

Isn't it better named Zend3?
It may be changed anytime, though.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Pierre Joye
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski  wrote:

> That said, I completely disagree with the "delayers", who also happen
> to be ones who have a repeated tendency to talk a lot more than they
> do.  Dmitry is one if the biggest php.net doers - and us can
> understand how it runs him the wrong way.

Excuse me? As one of the "delayers", we do a shit load of work and I
was one of the 1st to contribute to phpng, code and doc, before giving
up because of the constant moving and lack of sync possibility. I
never said that Dmitry does nothing or bad work. But rushing this RFC,
even if you may get it accepted, is a strategic mistake.

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Tjerk Meesters
Hi Dmitry,

On 25 Jul, 2014, at 6:09 am, Dmitry Stogov  wrote:

> any one may vote according to their thoughts
> I'm not going to persuade any one.
> I already know the opinion of the majority.
> 
> Unfortunately, now many people lessen to the guys who speaks a lot.
> I  was never able to do it :),  but ... look into results we provide.
> They are more expressive than any words.

First of all, kudos for all the hard you and the team have been putting into 
this :)

From a developer’s point of view it would be nice to see a write-up of some of 
the changes that were made to the API's; I’m currently aware of the array 
(hash) API changes which are definitely an improvement over the old one, but 
there may be more that could also use an “idiom conversion guide”.


> 
> Thanks. Dmitry,
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig  wrote:
> 
>> 
>> 
>> 
>> On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov  wrote:
>> 
>>> one week - two weeks - months - years.
>>> I'll wait.
>>> I know what I'm doing. I'll make it.
>>> 
>>> Dmitry.
>>> 
>>> 
>>> On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye 
>>> wrote:
>>> 
 
 On Jul 24, 2014 10:13 PM, "Dmitry Stogov"  wrote:
> 
> agree,
> 
> I just don't see any blockers, except for Pierre.
 
 Come on Dmitry, I am not the only who has asked that.
 
>>> 
>> 
>> Just to throw in my usual two-cents, it seems to me that this RFC is very
>> premature.  It's the same sort of over-eagerness I saw in the front-page
>> news post a few weeks back.  I understand what you guys are trying to
>> accomplish and I applaud you for it, but as far as I can see, it's still
>> quite a ways away from being ready for prime time.  And yet, you seem to be
>> acting like it's already there.
>> 
>> Aside from the code needing to be ready/tested, you also need to have a
>> more matured collaboration with community folks outside your project like
>> Pierre, which at the moment appears to be downright hostile.  Even if the
>> code looked great and everything else was in place, I would never vote to
>> switch over to such a drastic new schema when there's this much animosity
>> and controversy surrounding it.  I keep reading complaints about questions
>> being ignored and conflicting stories about secrecy and process.  I also
>> think there's some merit to the concern raised about the ambiguity being a
>> prelude to patches being rejected over trivial concerns.
>> 
>> I think you guys need to slow down and mend a few fences if you want to
>> make this happen.  As much as I like the goals of this project, I'm forced
>> to vote -1 for now, as well.  I just think you're jumping the gun when
>> there are too many unanswered questions/concerns still out there.
>> 
>> --Kris
>> 
>> 


Best,
  Tjerk


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Zeev Suraski
> On 25 ביול 2014, at 01:35, Jan Ehrhardt  wrote:
>
> Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400):
>> I already know the opinion of the majority.
>
> Do you also know the opinion of 2/3 of the voters?

Guys,

Let's deescalate here.  Dmitry is understandably quite emotionally
attached to this.  I probably wouldn't have sent the emails he sent
tonight on this thread had I been him - but I'm not...

I agree with Nikita - there's no reason to shorten the mandatory 2wk
cycle and I'd reply with no had others not beat me to it.  I'd be
highly annoyed if it was done to me on an RFC I care about.

That said, I completely disagree with the "delayers", who also happen
to be ones who have a repeated tendency to talk a lot more than they
do.  Dmitry is one if the biggest php.net doers - and us can
understand how it runs him the wrong way.

The main missing piece was docs, and we made some progress there - but
probably need some more time for people to provide feedback and
adjust.  Other than that I see absolutely no reason to stall beyond
the 2wk discussion period, and every reason to floor the has pedal.

I don't know what the voting outcome would be, but as I wrote in the
RFC - I hope it will be well above 2/3, so that we have an awesome
engine to match the shiny new version number :)

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Kris Craig
On Thu, Jul 24, 2014 at 3:39 PM, Zeev Suraski  wrote:

> > On 25 ביול 2014, at 01:35, Jan Ehrhardt  wrote:
> >
> > Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400):
> >> I already know the opinion of the majority.
> >
> > Do you also know the opinion of 2/3 of the voters?
>
> Guys,
>
> Let's deescalate here.  Dmitry is understandably quite attached to this


Very much agreed!  I'd love to see cooler heads prevail on this.  I see no
reason why both sides can't come together on this if they'd just drop all
this posturing.  Supporters should slow down and take the time to answer
questions and build consensus.  Critics should remember that these guys
have put a lot of work into it and are understandably eager to see it come
to fruition.  I think that would make this a much more constructive, much
less melodramatic process.  And I'd certainly be inclined to vote in favor
of it once it's no longer a matter of heated controversy.  =)

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Zeev Suraski
> On 25 ביול 2014, at 01:35, Jan Ehrhardt  wrote:
>
> Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400):
>> I already know the opinion of the majority.
>
> Do you also know the opinion of 2/3 of the voters?

Guys,

Let's deescalate here.  Dmitry is understandably quite attached to this

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Jan Ehrhardt
Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400):
>I already know the opinion of the majority.

Do you also know the opinion of 2/3 of the voters?

Jan (without voting right BTW)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
any one may vote according to their thoughts
I'm not going to persuade any one.
I already know the opinion of the majority.

Unfortunately, now many people lessen to the guys who speaks a lot.
I  was never able to do it :),  but ... look into results we provide.
They are more expressive than any words.

Thanks. Dmitry,








On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig  wrote:

>
>
>
> On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov  wrote:
>
>> one week - two weeks - months - years.
>> I'll wait.
>> I know what I'm doing. I'll make it.
>>
>> Dmitry.
>>
>>
>> On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye 
>> wrote:
>>
>> >
>> > On Jul 24, 2014 10:13 PM, "Dmitry Stogov"  wrote:
>> > >
>> > > agree,
>> > >
>> > > I just don't see any blockers, except for Pierre.
>> >
>> > Come on Dmitry, I am not the only who has asked that.
>> >
>>
>
> Just to throw in my usual two-cents, it seems to me that this RFC is very
> premature.  It's the same sort of over-eagerness I saw in the front-page
> news post a few weeks back.  I understand what you guys are trying to
> accomplish and I applaud you for it, but as far as I can see, it's still
> quite a ways away from being ready for prime time.  And yet, you seem to be
> acting like it's already there.
>
> Aside from the code needing to be ready/tested, you also need to have a
> more matured collaboration with community folks outside your project like
> Pierre, which at the moment appears to be downright hostile.  Even if the
> code looked great and everything else was in place, I would never vote to
> switch over to such a drastic new schema when there's this much animosity
> and controversy surrounding it.  I keep reading complaints about questions
> being ignored and conflicting stories about secrecy and process.  I also
> think there's some merit to the concern raised about the ambiguity being a
> prelude to patches being rejected over trivial concerns.
>
> I think you guys need to slow down and mend a few fences if you want to
> make this happen.  As much as I like the goals of this project, I'm forced
> to vote -1 for now, as well.  I just think you're jumping the gun when
> there are too many unanswered questions/concerns still out there.
>
> --Kris
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Kris Craig
On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov  wrote:

> one week - two weeks - months - years.
> I'll wait.
> I know what I'm doing. I'll make it.
>
> Dmitry.
>
>
> On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye 
> wrote:
>
> >
> > On Jul 24, 2014 10:13 PM, "Dmitry Stogov"  wrote:
> > >
> > > agree,
> > >
> > > I just don't see any blockers, except for Pierre.
> >
> > Come on Dmitry, I am not the only who has asked that.
> >
>

Just to throw in my usual two-cents, it seems to me that this RFC is very
premature.  It's the same sort of over-eagerness I saw in the front-page
news post a few weeks back.  I understand what you guys are trying to
accomplish and I applaud you for it, but as far as I can see, it's still
quite a ways away from being ready for prime time.  And yet, you seem to be
acting like it's already there.

Aside from the code needing to be ready/tested, you also need to have a
more matured collaboration with community folks outside your project like
Pierre, which at the moment appears to be downright hostile.  Even if the
code looked great and everything else was in place, I would never vote to
switch over to such a drastic new schema when there's this much animosity
and controversy surrounding it.  I keep reading complaints about questions
being ignored and conflicting stories about secrecy and process.  I also
think there's some merit to the concern raised about the ambiguity being a
prelude to patches being rejected over trivial concerns.

I think you guys need to slow down and mend a few fences if you want to
make this happen.  As much as I like the goals of this project, I'm forced
to vote -1 for now, as well.  I just think you're jumping the gun when
there are too many unanswered questions/concerns still out there.

--Kris


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
one week - two weeks - months - years.
I'll wait.
I know what I'm doing. I'll make it.

Dmitry.


On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye  wrote:

>
> On Jul 24, 2014 10:13 PM, "Dmitry Stogov"  wrote:
> >
> > agree,
> >
> > I just don't see any blockers, except for Pierre.
>
> Come on Dmitry, I am not the only who has asked that.
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Pierre Joye
On Jul 24, 2014 10:13 PM, "Dmitry Stogov"  wrote:
>
> agree,
>
> I just don't see any blockers, except for Pierre.

Come on Dmitry, I am not the only who has asked that.


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
agree,

I just don't see any blockers, except for Pierre.

Lets wait a week.

Thanks, Dmitry.


On Fri, Jul 25, 2014 at 12:01 AM, Nikita Popov  wrote:

> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:
>
>> 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
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
You talk not about starting the voting, you talk about your opinion.

Anyway. No problem I can wait another week and start the voting according
to all the rules.

Dmitry.








On Thu, Jul 24, 2014 at 11:55 PM, Pierre Joye  wrote:

>
> On Jul 24, 2014 9:45 PM, "Dmitry Stogov"  wrote:
> >
> > Vote -1, I won't be surprised.
> >
> > I'm asking if we have any stoppers to start the voting, if we have
> nothing to discuss.
> >
> > The porting guide is almost ready now, but it never be 100% ready to
> someones.
>
> It is the stopper and not only the migration guide. We need to know what
> has been done to do an informed vote. We also need to know what else is
> coming, readiness for changes etc.
>
> Voting now means giving you a blank card and simply accept anything and
> expose us to what already happened too many times, rejecting patches with
> no good reasons.
>
> > Thanks. Dmitry.
> >
> >
> > On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye 
> wrote:
> >>
> >> hi Dmitry,
> >>
> >> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:
> >> > 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
> >
> >
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Nikita Popov
On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:

> 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


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Pierre Joye
On Jul 24, 2014 9:45 PM, "Dmitry Stogov"  wrote:
>
> Vote -1, I won't be surprised.
>
> I'm asking if we have any stoppers to start the voting, if we have
nothing to discuss.
>
> The porting guide is almost ready now, but it never be 100% ready to
someones.

It is the stopper and not only the migration guide. We need to know what
has been done to do an informed vote. We also need to know what else is
coming, readiness for changes etc.

Voting now means giving you a blank card and simply accept anything and
expose us to what already happened too many times, rejecting patches with
no good reasons.

> Thanks. Dmitry.
>
>
> On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye 
wrote:
>>
>> hi Dmitry,
>>
>> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:
>> > 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
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
Vote -1, I won't be surprised.

I'm asking if we have any stoppers to start the voting, if we have nothing
to discuss.

The porting guide is almost ready now, but it never be 100% ready to
someones.

Thanks. Dmitry.


On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye  wrote:

> hi Dmitry,
>
> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:
> > 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
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Pierre Joye
hi Dmitry,

On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov  wrote:
> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
The "the" before "start" is a mistake :)


On Thu, Jul 24, 2014 at 11:04 PM, Dmitry Stogov  wrote:

> 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.
>
>
>
> On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski  wrote:
>
>> > -Original Message-
>> > From: Stas Malyshev [mailto:smalys...@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
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-24 Thread Dmitry Stogov
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.



On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski  wrote:

> > -Original Message-
> > From: Stas Malyshev [mailto:smalys...@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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


RE: [PHP-DEV] RFC: Move phpng to master

2014-07-23 Thread Zeev Suraski
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-23 Thread Lester Caine
On 23/07/14 13:05, Zeev Suraski wrote:
>> It does sound very much as if
>> > phpng is already a done deal and it just need to be rubber stamped into
>> > the main development stream?
> It's not a rubber stamp.  If you don't feel it should make it in and enough 
> people will think like you, then it won't make it in.  I think this would be 
> an enormous strategic mistake for the project, but it's a possibility.
> You're right that we're not going to write an RFC for each and every of the 
> countless changes we made.  It's a vote on embracing the entire refactored 
> codebase, or rejecting it.
> 
>> > my own concern as
>> > always is the effect on extensions I use. These sorts of substantial
>> > reworks broke interbase for many versions back in the 5.0/5.1 days and
>> > it was not until 5.1.6 that a working version was restored! Interbase is
>> > not even included in phpng yet ... as are other database interfaces ...
>> > areas where performance can be tuned by offloading work rather than
>> > downloading data unnecessarily.
> Assuming someone takes the time to do the necessary fixes to the Interbase 
> extension, then there shouldn't be a problem.  Like any other extension in 
> PHP, things can get messy if there's no maintainer for the extension;  I 
> don't know if the Interbase extension has one, but if not, it may take a 
> while for it to be upgraded or we might have to consider deprecating it 
> (hopefully not).  Taking your 5.x example, even though life was tough for 
> Interbase users between 5.0 and 5.1.6, I hardly think that we should have 
> delayed for two years and a month (the time that passed between 5.0.0 and 
> 5.1.6) because that extension had no maintainer...

Thanks for that ...
I WOULD spend time on maintaining, but there are only so many hours in
the day and I've STILL got at least a dozen sites on 5.2 which need some
TLC :( The plan is to get everything onto 5.4 this year but the
continual fight with browser niggles messing up sites that have already
been upgraded, and customers keep asking for changes they can't do
themselves ... not sure even that is going to happen :(

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-23 Thread Zeev Suraski
On 22 ביול 2014, at 15:39, Lester Caine  wrote:
> It does sound very much as if
> phpng is already a done deal and it just need to be rubber stamped into
> the main development stream?

It's not a rubber stamp.  If you don't feel it should make it in and enough 
people will think like you, then it won't make it in.  I think this would be an 
enormous strategic mistake for the project, but it's a possibility.
You're right that we're not going to write an RFC for each and every of the 
countless changes we made.  It's a vote on embracing the entire refactored 
codebase, or rejecting it.

> my own concern as
> always is the effect on extensions I use. These sorts of substantial
> reworks broke interbase for many versions back in the 5.0/5.1 days and
> it was not until 5.1.6 that a working version was restored! Interbase is
> not even included in phpng yet ... as are other database interfaces ...
> areas where performance can be tuned by offloading work rather than
> downloading data unnecessarily.

Assuming someone takes the time to do the necessary fixes to the Interbase 
extension, then there shouldn't be a problem.  Like any other extension in PHP, 
things can get messy if there's no maintainer for the extension;  I don't know 
if the Interbase extension has one, but if not, it may take a while for it to 
be upgraded or we might have to consider deprecating it (hopefully not).  
Taking your 5.x example, even though life was tough for Interbase users between 
5.0 and 5.1.6, I hardly think that we should have delayed for two years and a 
month (the time that passed between 5.0.0 and 5.1.6) because that extension had 
no maintainer...

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Stas Malyshev
Hi!

> As we’re getting closer to release 5.6.0, and given the very high
> level of interest in phpng, I think it’s time for us to provide some
> clarity regarding what happens post 5.6.0.
> 
> Dmitry and I wrote an RFC proposing that we merge phpng into master
> and turn it into the basis of the next major version of PHP (name
> TBD).

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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Philip Hofstetter
Hi,

On Tue, Jul 22, 2014 at 3:18 PM, Etienne Kneuss  wrote:

> This means https://wiki.php.net/phpng-upgrading should be completed to
> reflect all changes.

as a pure consumer maintaining some internal extensions, I would very
much like to see this too, at least when you decide to go ahead with
the merge.

Btw: I have, of course, no say on this as a pure consumer, but there
was the discussion of whether the performance improvement alone
without any other features would already make consumers excited. To
which I can say: Heck yeah.

Me personally, I would be very happy to see the speed improvement and
I have zero issues in adopting our internal extensions to the new API,
especially when it's for a new major release.

Philip

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Ferenc Kovacs
On Tue, Jul 22, 2014 at 4:10 PM, Matteo Beccati  wrote:

> On 22/07/2014 15:37, Derick Rethans wrote:
> > On Tue, 22 Jul 2014, Etienne Kneuss wrote:
> >
> >> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski  wrote:
> >>
> >>> Once the RFC is approved (I hope)
> >>
> >> Before the merge RFC can be considered for voting, I think it is
> >> critical that you provide a comprehensive migration guide highlighting
> >> the changes required from core developers. This means
> >> https://wiki.php.net/phpng-upgrading should be completed to reflect
> >> all changes.
> >>
> >> It is only then that we can vote with knowledge of how much this big
> >> patch affects the codebase.
> >
> > *this* is something I very much would like to see too.
>
> I agree.
>
> It might sound silly, but it would also be interesting to know what
> could be the effect of phpng on the potential ideas for php6/7 from
> https://wiki.php.net/ideas/php6 (if any).
>
> For most of them it's pretty clear that there's isn't an overlap, but
> how about unicode support? Its implementation might undo or reduce some
> of the performance gains obtained in phpng. Or, if you put it the other
> way around: if we merge phpng to master it might not be acceptable to
> think about adding utf8 support.
>

One can make wishlists, but I don't think we have any people who is
familiar with the area and willing to work for this to
happen(unfortunately).
Of course such a person/group of people can step up and would be welcome to
do so, but I see no point of trying to feature box a release without having
anybody actually working towards those goals.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Matteo Beccati
On 22/07/2014 15:37, Derick Rethans wrote:
> On Tue, 22 Jul 2014, Etienne Kneuss wrote:
> 
>> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski  wrote:
>>
>>> Once the RFC is approved (I hope)
>>
>> Before the merge RFC can be considered for voting, I think it is 
>> critical that you provide a comprehensive migration guide highlighting 
>> the changes required from core developers. This means 
>> https://wiki.php.net/phpng-upgrading should be completed to reflect 
>> all changes.
>>
>> It is only then that we can vote with knowledge of how much this big 
>> patch affects the codebase.
> 
> *this* is something I very much would like to see too.

I agree.

It might sound silly, but it would also be interesting to know what
could be the effect of phpng on the potential ideas for php6/7 from
https://wiki.php.net/ideas/php6 (if any).

For most of them it's pretty clear that there's isn't an overlap, but
how about unicode support? Its implementation might undo or reduce some
of the performance gains obtained in phpng. Or, if you put it the other
way around: if we merge phpng to master it might not be acceptable to
think about adding utf8 support.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Lester Caine
On 22/07/14 14:37, Derick Rethans wrote:
>> Before the merge RFC can be considered for voting, I think it is 
>> > critical that you provide a comprehensive migration guide highlighting 
>> > the changes required from core developers. This means 
>> > https://wiki.php.net/phpng-upgrading should be completed to reflect 
>> > all changes.
>> > 
>> > It is only then that we can vote with knowledge of how much this big 
>> > patch affects the codebase.
> *this* is something I very much would like to see too.

"Zend has a new zend_string API" would seem to merit a little more than
a single line?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Dmitry Stogov
I'll try to do this.
It would be great, if someone may help.

Thanks. Dmitry.


On Tue, Jul 22, 2014 at 5:18 PM, Etienne Kneuss 
wrote:

> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski  wrote:
>
> > Once the RFC is approved (I hope)
> >
>
> Before the merge RFC can be considered for voting, I think it is critical
> that you provide a comprehensive migration guide highlighting the changes
> required from core developers.
> This means https://wiki.php.net/phpng-upgrading should be completed to
> reflect all changes.
>
> It is only then that we can vote with knowledge of how much this big patch
> affects the codebase.
>
> Best,
> --
> Etienne Kneuss
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Derick Rethans
On Tue, 22 Jul 2014, Etienne Kneuss wrote:

> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski  wrote:
> 
> > Once the RFC is approved (I hope)
> 
> Before the merge RFC can be considered for voting, I think it is 
> critical that you provide a comprehensive migration guide highlighting 
> the changes required from core developers. This means 
> https://wiki.php.net/phpng-upgrading should be completed to reflect 
> all changes.
> 
> It is only then that we can vote with knowledge of how much this big 
> patch affects the codebase.

*this* is something I very much would like to see too.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Etienne Kneuss
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski  wrote:

> Once the RFC is approved (I hope)
>

Before the merge RFC can be considered for voting, I think it is critical
that you provide a comprehensive migration guide highlighting the changes
required from core developers.
This means https://wiki.php.net/phpng-upgrading should be completed to
reflect all changes.

It is only then that we can vote with knowledge of how much this big patch
affects the codebase.

Best,
-- 
Etienne Kneuss


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Zeev Suraski
On 22 ביול 2014, at 15:17, Ferenc Kovacs  wrote:

> Hi Zeev,
> 
> The discussion seems to be sidetracked by the topic on when should we release 
> PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later, 
> after we managed to have a consensus on merging phpng to master?
> I think that it is an important question, but not having phpng in master 
> block the other features/changes as well, and we don't have to decide about 
> the roadmap/features for PHP-NEXT right now.
> Thanks for your understanding!

I wholeheartedly agree with you, we absolutely can postpone it -  the RFC 
doesn't deal with that actually.  Once the RFC is approved (I hope), I think 
we'd then need to discuss fairly quickly what we aim for - a release sometime 
next year or later.  Until that happens, I think we should make no assumptions 
on 5.7 (which is what started the timeline discussion) - one way or the other.

Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Pierre Joye
On Tue, Jul 22, 2014 at 2:17 PM, Ferenc Kovacs  wrote:

> Hi Zeev,
>
> The discussion seems to be sidetracked by the topic on when should we
> release PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later,
> after we managed to have a consensus on merging phpng to master?

I do not think it is reasonable to do so. Empty promises are never
met. Once it is in, we will be doomed, blocking additions or change in
the name of a 1% perf etc will be common, let alone migration guides,
documentations, etc.

> I think that it is an important question, but not having phpng in master
> block the other features/changes as well, and we don't have to decide about
> the roadmap/features for PHP-NEXT right now.
> Thanks for your understanding!

None of the worries have been solved, so we are going to vote on given
phpng white card and hope everything will be fine. History told me
that it does not work. On the hand, some clear statements about the
numerous questions raised here, updated docs and migrations guide,
list of actual changes and how, all these things will help to take an
informed decisions instead of shooting in the dark and hoping for the
best.

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Lester Caine
On 22/07/14 13:17, Ferenc Kovacs wrote:
> The discussion seems to be sidetracked by the topic on when should we
> release PHP-NEXT and what else should it contains.
> Could we agree to put that aside for now, and agree to discuss this later,
> after we managed to have a consensus on merging phpng to master?
> I think that it is an important question, but not having phpng in master
> block the other features/changes as well, and we don't have to decide about
> the roadmap/features for PHP-NEXT right now.

PHPNext is a side issue as it does not need phpng ...

What seems to be missing here is any real possibility of a review of all
the aspects of phpng and IF each of those make sense - in light of
developments others have been working on. It does sound very much as if
phpng is already a done deal and it just need to be rubber stamped into
the main development stream? There has been complaints about not being
able to review decisions made behind closed doors but my own concern as
always is the effect on extensions I use. These sorts of substantial
reworks broke interbase for many versions back in the 5.0/5.1 days and
it was not until 5.1.6 that a working version was restored! Interbase is
not even included in phpng yet ... as are other database interfaces ...
areas where performance can be tuned by offloading work rather than
downloading data unnecessarily.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Ferenc Kovacs
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski  wrote:

>
>
> 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
>
>
>

Hi Zeev,

The discussion seems to be sidetracked by the topic on when should we
release PHP-NEXT and what else should it contains.
Could we agree to put that aside for now, and agree to discuss this later,
after we managed to have a consensus on merging phpng to master?
I think that it is an important question, but not having phpng in master
block the other features/changes as well, and we don't have to decide about
the roadmap/features for PHP-NEXT right now.
Thanks for your understanding!

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Ferenc Kovacs
On Tue, Jul 22, 2014 at 12:15 PM, Nikita Popov  wrote:

> On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs  wrote:
>
>> On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui  wrote:
>>
>> > Hey:
>> >
>> >  I really don't like arguing in english, so this will be my last
>> > reply in this thread.
>> >
>>
>> sorry to bother you, and my "backlash" wasn't really targeted you
>> personally.
>>
>>
>> >
>> > On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs 
>> wrote:
>> > > https://wiki.php.net/rfc/uniform_variable_syntax
>> > > https://wiki.php.net/rfc/size_t_and_int64_next
>> >
>> > aren't they discussed and voted? what do you mean by  we can't even
>> > start in previous comment?
>>
>> yes, and both of those were put on hold by the authors until the phpng
>> situation is resolved, and to me it feels wrong to block something which
>> is
>> done and accepted with something which is not-yet finished(albeit it seems
>> to be reaching a stable state) and didn't have a consensus behind it.
>>
>
> To make sure that this isn't misconstrued as an argument against merging
> phpng: My work isn't blocked by phpng (it's actually based on it), it's
> blocked by lack of an official decision regarding phpng. I have another
> large patch (AST) based on phpng and Andrea is working on a bigint
> implementation, also based on phpng. Before these things can move forward
> we need the decision that PHP 6/7 is going to be based on phpng.
>

sorry if I wasn't clear enough, this is exactly what I meant by "but we
can't even start because *there is no stable base to target the other
php-next* features.".
I should have quoted your mail where you mention that you will put on hold
until the master-phpng situation is resolved.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Pierre Joye
On Tue, Jul 22, 2014 at 12:11 PM, Benjamin Eberlei  wrote:
> On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye  wrote:
>>
>> On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei 
>> wrote:
>>
>> > This is the opportunity to do the cleanup now, based on phpng branch.
>> > Since
>> > the branch is pulic on Github, how is development secret?
>>
>> Benjamin, please check the background before replying. 80% of phpng
>> development has been done secretly, before it was even announced. This
>> development happened while we were discussing, collaborating, working
>> on what will be php-next, including the long due 64bit patch. These
>> actions and discussion have done without any feedback from any of the
>> phpng developers. I can't blame them for not talking about phpng, but
>> to have signed a NDA to do work on PHP itself.
>
>
> I know the background and the int64 clash was unfortunate, however it was
> resolved from what I see in a good compromise.

There was no compromise but forcing a move on something that does not
exist yet. We made the step to propose a merge with phpng if phpng is
ever accepted. No step done from the phpng team, in contrary. So much
about coop and trust of said promises.

> I don't see how starting to work on some feature/refactoring requires
> immediate communication with all of the team, since you need to prove it
> works first, obviously you have the prototype then, which is always kind of
> secret, because you are the only one who worked on it.

There is a huge difference between working on a specific feature and
do a total rewamp of the core, breaking APIs even more, for months,
ignoring discussions about the exact same topic, let other waste
*months* of work by doing so. Even have the mood to say that there is
no plan to replace master with phpng and then come up with such
proposal. I am sorry, but I totally fail to understand that we could
even consider this behavior as good or normal.

> Everybody can put their own time where they want in Open-Source, and since
> After the initial prototype there was the announcment, no ninja merge or
> similar, discussion is still possible. But this requires constructive review
> of the patches and pull requests, like its done in any project I worked on
> (Symfony, Doctrine, ..). Instead this discussion has already gone south
> again discussing about politics instead of the actual code.

What you see as politics, I see it as the core issues in why the PHP
project does not work as team.


>> > With Zend, Nikita
>> > and laurence putting so much time into this, I fail to see how it would
>> > work
>> > to notify everyone of all the changes they are doing. As with every big
>> > project you have to put time into following its progress. I agree though
>> > that Zend (Zeev, Dimitry) could improve the RFC with a little more
>> > details,
>> > its focussing a lot on performance.
>>
>> A little? There is no details, there is no doc, there is nothing but a
>> huge set of patches.
>>
>> > As i understood Nikita and laurence they are already improving it based
>> > on
>> > the first prototype from month ago. Honestly, if Nikita says converting
>> > his
>> > extensions improved the API a lot then this is a good sign for me
>> > already.
>>
>> It does not improve anything from an extension developer point of
>> view, or very little. On the other APIs are more dangerous, confusing
>> and inconsistent.
>
>
> So there is your opinion aginst Nikita's. He has already ported his
> extensions and gave a positive opinion.

Well, seriously, are you surprised that one of the phpng developer
likes what phpng changes? I am not. And phpng solves none of the
current APIs issue and code awful state. I am not alone to say it and
I am not alone to see it.


> PHP 5.3, 5.4 and 5.5 had fantastic feature additions and they are only minor
> releases.
>
> I am a strong supporter of those features, however they have been voted out
> several times, so I have accepted that they will probably be never in the
> Core. I don't mind, they are just syntactic glue, PHP works for me anyways.
>
> What I would hate to see is that PHP 6/7 blocks itself by wanting to be too
> much, failing again or delaying years like PHP 5.3. I agree with Zeev that
> if phpng is going to be master, then this should be released sometime next
> year.

No way. It is impossible and there is so much chances to fuck it up by
rushing it this way. And as usual, we will have to take of this mess
for the next decade. This is not something I can live with.

> Btw, it is your credit that we have the RFC process now, so i fail to see
> how this would mean we have another 10 years of PHP 6/7 deadlock, the
> release schedule increased massively since then and I expect this to
> continue, even more so with the HHVM competition.

That being said, between one year and six years there is a medium way.
And this is the way I strongly recommend.

What you do not seem to see or understand is that engine/core
refactoring can't and won't hap

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Nikita Popov
On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs  wrote:

> On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui  wrote:
>
> > Hey:
> >
> >  I really don't like arguing in english, so this will be my last
> > reply in this thread.
> >
>
> sorry to bother you, and my "backlash" wasn't really targeted you
> personally.
>
>
> >
> > On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs 
> wrote:
> > > https://wiki.php.net/rfc/uniform_variable_syntax
> > > https://wiki.php.net/rfc/size_t_and_int64_next
> >
> > aren't they discussed and voted? what do you mean by  we can't even
> > start in previous comment?
>
> yes, and both of those were put on hold by the authors until the phpng
> situation is resolved, and to me it feels wrong to block something which is
> done and accepted with something which is not-yet finished(albeit it seems
> to be reaching a stable state) and didn't have a consensus behind it.
>

To make sure that this isn't misconstrued as an argument against merging
phpng: My work isn't blocked by phpng (it's actually based on it), it's
blocked by lack of an official decision regarding phpng. I have another
large patch (AST) based on phpng and Andrea is working on a bigint
implementation, also based on phpng. Before these things can move forward
we need the decision that PHP 6/7 is going to be based on phpng.

Nikita


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Benjamin Eberlei
On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye  wrote:

> On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei 
> wrote:
>
> > This is the opportunity to do the cleanup now, based on phpng branch.
> Since
> > the branch is pulic on Github, how is development secret?
>
> Benjamin, please check the background before replying. 80% of phpng
> development has been done secretly, before it was even announced. This
> development happened while we were discussing, collaborating, working
> on what will be php-next, including the long due 64bit patch. These
> actions and discussion have done without any feedback from any of the
> phpng developers. I can't blame them for not talking about phpng, but
> to have signed a NDA to do work on PHP itself.
>

I know the background and the int64 clash was unfortunate, however it was
resolved from what I see in a good compromise.

I don't see how starting to work on some feature/refactoring requires
immediate communication with all of the team, since you need to prove it
works first, obviously you have the prototype then, which is always kind of
secret, because you are the only one who worked on it.

Everybody can put their own time where they want in Open-Source, and since
After the initial prototype there was the announcment, no ninja merge or
similar, discussion is still possible. But this requires constructive
review of the patches and pull requests, like its done in any project I
worked on (Symfony, Doctrine, ..). Instead this discussion has already gone
south again discussing about politics instead of the actual code.


>
> > With Zend, Nikita
> > and laurence putting so much time into this, I fail to see how it would
> work
> > to notify everyone of all the changes they are doing. As with every big
> > project you have to put time into following its progress. I agree though
> > that Zend (Zeev, Dimitry) could improve the RFC with a little more
> details,
> > its focussing a lot on performance.
>
> A little? There is no details, there is no doc, there is nothing but a
> huge set of patches.
>
> > As i understood Nikita and laurence they are already improving it based
> on
> > the first prototype from month ago. Honestly, if Nikita says converting
> his
> > extensions improved the API a lot then this is a good sign for me
> already.
>
> It does not improve anything from an extension developer point of
> view, or very little. On the other APIs are more dangerous, confusing
> and inconsistent.
>

So there is your opinion aginst Nikita's. He has already ported his
extensions and gave a positive opinion.

>
> >>
> >>
> >> The other important parts are things like type hinting for scalar, to
> >> match the class type hinting, getter/setter (100% positive feedback to
> >> do what we proposed in the related RFC), object like methods for
> >> array/string, keeping BC with the existing APIs but providing cleaner
> >> userfriendlier APIs, etc. It is basically what we can find in the
> >> ideas page about php6, a page I created months ago and began to
> >> discuss. These discussions happened here, publically, and you
> >> (phpng's) never replied to any of them. This is what we should discuss
> >> now, not tomorrow, not when phpng is merged (if it ever happens). This
> >> is what allows us to do an informed guess for a possible release cycle
> >> for php-next. I will post a proposal for a timetable, something that
> >> could fit for both sides. Do not expect it to match your one year
> >> requirement, but it won't be three years either.
> >
> >
> > I think internal refactoring is exactly the reason to move from 5 to 6/7
> and
> > not necessarily end user facing changes. i wouldn't mind starting type
> > hinting, getter/setter or any other discussion again once a 6.0/7.0 is
> out.
> > This has worked for PHP since 5.3, 5.4, 5.5.
>
> Again once it is out? In which world do you live? that will never
> happen. We have an opportunity now to do it, let do it. Also I am very
> surprised to read that from you, I thought you were a strong supporter
> of these features, or annotations.
>

PHP 5.3, 5.4 and 5.5 had fantastic feature additions and they are only
minor releases.

I am a strong supporter of those features, however they have been voted out
several times, so I have accepted that they will probably be never in the
Core. I don't mind, they are just syntactic glue, PHP works for me anyways.

What I would hate to see is that PHP 6/7 blocks itself by wanting to be too
much, failing again or delaying years like PHP 5.3. I agree with Zeev that
if phpng is going to be master, then this should be released sometime next
year.

Btw, it is your credit that we have the RFC process now, so i fail to see
how this would mean we have another 10 years of PHP 6/7 deadlock, the
release schedule increased massively since then and I expect this to
continue, even more so with the HHVM competition.


>
> > I'd rather just take the performance gains, given that PHP as a language
> > just works(tm), additional fea

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Ferenc Kovacs
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui  wrote:

> Hey:
>
>  I really don't like arguing in english, so this will be my last
> reply in this thread.
>

sorry to bother you, and my "backlash" wasn't really targeted you
personally.


>
> On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs  wrote:
> >
> >
> >
> > On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui  wrote:
> >>
> >> Hey:
> >>
> >> > 在 2014年7月21日,19:02,Ferenc Kovacs  写道:
> >> >
> >> >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> 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
> >> >
> >> > because there is so much stuff which we want to do in the next major
> >> > version, but we can't even start because there is no stable base to
> >> > target
> >> > the other php-next features.
> >> What they are?  Please come with RFC and Patches.
> >
> >
> > https://wiki.php.net/rfc/uniform_variable_syntax
> > https://wiki.php.net/rfc/size_t_and_int64_next
>
> aren't they discussed and voted? what do you mean by  we can't even
> start in previous comment?
>

yes, and both of those were put on hold by the authors until the phpng
situation is resolved, and to me it feels wrong to block something which is
done and accepted with something which is not-yet finished(albeit it seems
to be reaching a stable state) and didn't have a consensus behind it.


> >
> >>
> >> Or you suggest we stop the current work to waiting them come their self?
> >
> >
> > I'm saying that we should resolve the current situation where people
> can't
> > work on stuff which would target php-next, because it is still a moving
> > target.
>
> why Nikita could work on it? why me can work on it?
>

I'm not saying that you should implement other people's RFCs.
we have a couple of options:

   - ignore phpng with the other RFCs/changes, and continue working on
   master, making it your problem to try to stabilize phpng while catching up
   to a constantly moving target, which is bad.
   - we could also continue the current trend that we simply don't merge
   stuff until phpng is voted and merged, which is bad
   - we could also work together to sort out the controversial
   topics/features about the current phpng branch, and figure out a way to
   either resolve the issues, or exclude those stuff from the initial merge,
   and have most of the phpng stuff merged into master, so we can start
   working together in a common branch instead of blocking each other.



>
> > I'm saying that it is nice that you(the phpng main devs) are confident
> that
> > you can stabilize your changes so making a php-next release in less than
> a
> > year, but other people have other ideas which can only happen in a major
> > version, and you shouldn't rush an early release which would mean that
> the
> > next window of opportunity for major refactor is in the next decade.
> I am not sure about you attitude here,  from these words,  seems you
> agree to merge phpng to master asap, then people can start work on it?
>

yes!

>
> > I'm saying that it is pretty unfortunate that we have to decide to
> between
> > reviewing/accepting a huuuge chunk of changes or rejecting a
> significant
> > performance boost and some api cleanup.
>
> we shouldn't,  at least most people here shouldn't,  only the guys who
> need to maintain them should.
>

what I wanted to say that it is better to review and merge smaller chunks
of changes.
I know that "You Can't Cross a Chasm in Two Small Steps", eg. that the
initial work has to be done, but I think what we have is already more than
enough for the initial merge.


>
> > I'm saying that we should stop pushing our own agendas, and figure out
> the
> > best possible solution for the current situation, so that we can go
> forward
> > with the development with the normal workflow, where everybody is on the
> > same page, controversial changes are done through RFCs and we don't block
> > each other from the work.
>
> you know what?  I really don't like "we should; we must", they means
> nothing..
>
> I have spent lots of my time to work on PHP/PHPNG,  more than 80 hours
> per month.
>
> I treat it like a regular work, dmitry spends more than me(8 hours per
> day).
>
> you ask me to stop to wait somebody who even can not work hours a month
> here?


> with all my respects:   I really upset by people who always told you,
> hey m

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Lester Caine
On 22/07/14 10:32, Pierre Joye wrote:
>> As i understood Nikita and laurence they are already improving it based on
>> > the first prototype from month ago. Honestly, if Nikita says converting his
>> > extensions improved the API a lot then this is a good sign for me already.
> It does not improve anything from an extension developer point of
> view, or very little. On the other APIs are more dangerous, confusing
> and inconsistent.

And unavailability of extensions is a blocker currently as well.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Pierre Joye
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei  wrote:

> This is the opportunity to do the cleanup now, based on phpng branch. Since
> the branch is pulic on Github, how is development secret?

Benjamin, please check the background before replying. 80% of phpng
development has been done secretly, before it was even announced. This
development happened while we were discussing, collaborating, working
on what will be php-next, including the long due 64bit patch. These
actions and discussion have done without any feedback from any of the
phpng developers. I can't blame them for not talking about phpng, but
to have signed a NDA to do work on PHP itself.

> With Zend, Nikita
> and laurence putting so much time into this, I fail to see how it would work
> to notify everyone of all the changes they are doing. As with every big
> project you have to put time into following its progress. I agree though
> that Zend (Zeev, Dimitry) could improve the RFC with a little more details,
> its focussing a lot on performance.

A little? There is no details, there is no doc, there is nothing but a
huge set of patches.

> As i understood Nikita and laurence they are already improving it based on
> the first prototype from month ago. Honestly, if Nikita says converting his
> extensions improved the API a lot then this is a good sign for me already.

It does not improve anything from an extension developer point of
view, or very little. On the other APIs are more dangerous, confusing
and inconsistent.

>>
>>
>> The other important parts are things like type hinting for scalar, to
>> match the class type hinting, getter/setter (100% positive feedback to
>> do what we proposed in the related RFC), object like methods for
>> array/string, keeping BC with the existing APIs but providing cleaner
>> userfriendlier APIs, etc. It is basically what we can find in the
>> ideas page about php6, a page I created months ago and began to
>> discuss. These discussions happened here, publically, and you
>> (phpng's) never replied to any of them. This is what we should discuss
>> now, not tomorrow, not when phpng is merged (if it ever happens). This
>> is what allows us to do an informed guess for a possible release cycle
>> for php-next. I will post a proposal for a timetable, something that
>> could fit for both sides. Do not expect it to match your one year
>> requirement, but it won't be three years either.
>
>
> I think internal refactoring is exactly the reason to move from 5 to 6/7 and
> not necessarily end user facing changes. i wouldn't mind starting type
> hinting, getter/setter or any other discussion again once a 6.0/7.0 is out.
> This has worked for PHP since 5.3, 5.4, 5.5.

Again once it is out? In which world do you live? that will never
happen. We have an opportunity now to do it, let do it. Also I am very
surprised to read that from you, I thought you were a strong supporter
of these features, or annotations.

> I'd rather just take the performance gains, given that PHP as a language
> just works(tm), additional features are nice, but not having them is not a
> show stopper and shouldn't block something as big as phpng.

It is. And performance is by no mean the main PHP problem, despite HHVM.

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Benjamin Eberlei
On Tue, Jul 22, 2014 at 10:45 AM, Pierre Joye  wrote:

> hi,
>
> On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski  wrote:
>
> >   I stand by my statement that I'm
> > sure a great deal of users (my guesstimate - the majority) would happily
> > upgrade to PHP.NEXT even if the huge performance gains were the only
> thing
> > there.
>
> Internals code cleanup is very very important point (more and more custom
> extensions are being
> internally developed, be OSS or not), our APIs and implemenation are a
> mess, we all know that. A cleanup is long due, since the php 4 to 5
> move.
>

This is the opportunity to do the cleanup now, based on phpng branch. Since
the branch is pulic on Github, how is development secret? With Zend, Nikita
and laurence putting so much time into this, I fail to see how it would
work to notify everyone of all the changes they are doing. As with every
big project you have to put time into following its progress. I agree
though that Zend (Zeev, Dimitry) could improve the RFC with a little more
details, its focussing a lot on performance.

As i understood Nikita and laurence they are already improving it based on
the first prototype from month ago. Honestly, if Nikita says converting his
extensions improved the API a lot then this is a good sign for me already.


>
> The other important parts are things like type hinting for scalar, to
> match the class type hinting, getter/setter (100% positive feedback to
> do what we proposed in the related RFC), object like methods for
> array/string, keeping BC with the existing APIs but providing cleaner
> userfriendlier APIs, etc. It is basically what we can find in the
> ideas page about php6, a page I created months ago and began to
> discuss. These discussions happened here, publically, and you
> (phpng's) never replied to any of them. This is what we should discuss
> now, not tomorrow, not when phpng is merged (if it ever happens). This
> is what allows us to do an informed guess for a possible release cycle
> for php-next. I will post a proposal for a timetable, something that
> could fit for both sides. Do not expect it to match your one year
> requirement, but it won't be three years either.
>

I think internal refactoring is exactly the reason to move from 5 to 6/7
and not necessarily end user facing changes. i wouldn't mind starting type
hinting, getter/setter or any other discussion again once a 6.0/7.0 is out.
This has worked for PHP since 5.3, 5.4, 5.5.

I'd rather just take the performance gains, given that PHP as a language
just works(tm), additional features are nice, but not having them is not a
show stopper and shouldn't block something as big as phpng.


>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Pierre Joye
hi,

On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski  wrote:

>   I stand by my statement that I'm
> sure a great deal of users (my guesstimate - the majority) would happily
> upgrade to PHP.NEXT even if the huge performance gains were the only thing
> there.

I fully agree with you about breakages. It should be carefully for
painful areas (like what is done in the variable syntax RFC) but big
breaks should be avoided.

However I disagree with your statement about what users expect for
next. It is obvious that users are happy to see PHP performing better,
there is no need to do a study to realize that. On the other hand,
performance is not their higher priorities for the next major version.
I spoke to many big php users, UG, etc in the last months and the
expectations go way beyond performance. Internals code cleanup is very
very important point (more and more custom extensions are being
internally developed, be OSS or not), our APIs and implemenation are a
mess, we all know that. A cleanup is long due, since the php 4 to 5
move. Back then you, along other, rejected many of these cleanup
arguing that it could be done later. Without blaming any of us, we see
now that we never do such things "later".

The other important parts are things like type hinting for scalar, to
match the class type hinting, getter/setter (100% positive feedback to
do what we proposed in the related RFC), object like methods for
array/string, keeping BC with the existing APIs but providing cleaner
userfriendlier APIs, etc. It is basically what we can find in the
ideas page about php6, a page I created months ago and began to
discuss. These discussions happened here, publically, and you
(phpng's) never replied to any of them. This is what we should discuss
now, not tomorrow, not when phpng is merged (if it ever happens). This
is what allows us to do an informed guess for a possible release cycle
for php-next. I will post a proposal for a timetable, something that
could fit for both sides. Do not expect it to match your one year
requirement, but it won't be three years either.

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Zeev Suraski
> -Original Message-
> From: Lester Caine [mailto:les...@lsces.co.uk]
> Sent: Tuesday, July 22, 2014 10:12 AM
> To: PHP internals
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
> Big users don't use PHP ...

Just to elaborate (slightly) on Dmitry's answer  - this is an absolutely
wrong and also fairly dangerous misconception.  PHP is the most widely used
dynamic language out there for web sites, and it's used by many of the
largest companies out there.  In fact, there are very few companies that
don't use PHP at all - whether it's for their main website or internal apps.

Judging by the response to my benchmarks post (10K views in the first 5
days, which I have to admit is very uncommon), the number of retweets,
questions and discussions it sparked - I'd say the level of interest is
very, very high.

I do recommend that instead of wasting time arguing about theory, at least
at this point, we focus on doing.  The first logical step (in my humble
opinion) is to move phpng into master and close any remaining gaps as
quickly as possible.
In parallel, people who want to get additional things into 6/7 should
hustle, instead of assuming they have 2-3 years of lingering to rely on.
RFCs we already agreed are going to be in the next version - like the
uniform variable syntax and the 64-bit patch - will make it into master
pretty quickly, I think we can count on Nikita here.

For 6/7, we should primarily focus on things that we can only do in a major
version - i.e. things that break compatibility.  We should do so while
keeping in mind that this is *not* an opportunity for wholesale breakage, as
then we risk very slow or no migration (like we had between 4 and 5).  New
features can be added in the yearly .1/.2 releases too - so if they make it
into .0 - great, but if not, no big deal.  I stand by my statement that I'm
sure a great deal of users (my guesstimate - the majority) would happily
upgrade to PHP.NEXT even if the huge performance gains were the only thing
there.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Dmitry Stogov
On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine  wrote:

> On 22/07/14 07:44, Dmitry Stogov wrote:
> > Big PHP users just can't not to care about performance, because it's
> money.
> > I know most of them already experimented with HHVM.
> Big users don't use PHP ...
>

You are wrong :)

Thanks. Dmitry.


>
> > If we don't provide adequate replay, we may turn back into the language
> for
> > home pages.
> Is that such a bad thing?
> Perhaps it is time there was a PHPHome and PHPCommercial ?
> Perhaps that is the problem these days :(
>

> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Lester Caine
On 22/07/14 07:44, Dmitry Stogov wrote:
> Big PHP users just can't not to care about performance, because it's money.
> I know most of them already experimented with HHVM.
Big users don't use PHP ...

> If we don't provide adequate replay, we may turn back into the language for
> home pages.
Is that such a bad thing?
Perhaps it is time there was a PHPHome and PHPCommercial ?
Perhaps that is the problem these days :(

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Lester Caine
On 22/07/14 03:58, Pierre Joye wrote:
> Now, as I already suggested many times (but with zero reply from
> Zend's), let step back, get our roadmap setup, todos, goals, agreement
> and get back to work. But a forcing move to php-next within a year
> with almost only phpng is a major mistake and will most likely create
> a major problem within the php community, especially for php.net. We
> are not in a positiion to do such mistake,. It is time to get our
> stuff together, to work as a team, this is out last chance, and phpng
> is not worth it in comparison.

Perhaps it may surprise some people, but I totally agree with Pierre
here. Given that the majority of MY time is spent these days trying to
play catchup, I am only really interested in fixing the remaining holes
in the user end of PHP. Rebuilding the guts really has little interest
... I've been through the same exercise with Firebird and we still use
the older versions because it does the job! Much of the esoteric
additions to PHP have absolutely no interest to me and in many cases
it's these which are creating the problems phpng is now trying to fix?

When I started at this lark 10+ years ago I could write PHP5 code that
gracefully rolled back to PHP4 and just worked. These days I'm not even
sure exactly what I'm even trying to fix ... I just work through a list
of warnings ... that is AFTER I get rid of the white screens! NOT having
control over much of the shared hosting environment I'm having to work
with, the current spread of incompatible configurations is a major
roadblock, and what is stopping even PHP5.2 from being phased out :(

Perhaps it IS time to reinstate PHP6! We know what the mistakes were and
have a better understanding of how things should have been done. With
the rest of the world already using Unicode and 64bit hardware, it's
these areas that need putting to bed in the core which is much more
important than a major code rework. Then phpng can be PHP7. Trying to
continue to shoehorn improvements into PHP5.x without the flexibility to
break the bits that DO need breaking is what is holding up progress, and
if phpng has been developed properly then it can be merged in again
later ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-22 Thread Yasuo Ohgaki
Hi David,

On Tue, Jul 22, 2014 at 2:42 PM, David Soria Parra  wrote:

> >
> > Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
> > any new feature will end up with master, I suppose. If a new feature is
> > only available to PHP-5.7 branch, it's a merge bug, isn't it?
> >
> > Regards,
>
> We had this policy before and it didn't help us. The problem is
> maintiaining all the branches and keeping people interested in the next
> branch because people tend to focus on the currently release branch.
> When we decided upon the release RFC we talked a lot about the overhead
> of maintaing multiple branches and tried to reduce the amount of
> branches. In particular with API changes it becomes tidious if we try to
> maintain a feature across branches and that implicit divergence has to
> be resolved better sooner or later, or otherwise it would be just like
> the old php6 again.


I can understand your concern. We have git now and git can easily spot what
and who haven't merged required changes to master. Working with multiple
branches and merge is much easier with git also. I think this time it will
work,
hopefully.

My concern is development time. It's too short. We only have about half of
a year to feature freeze. More than a year would be appropriate for a major
version up, IMHO. Long alpha/beta period is good for users also.

Having PHP-5.7 is not a mandatory, but I would like to have it.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Dmitry Stogov
Pierre,

I don't replay to you, because it's bad for my health. Many people here
would agree with me.
I prefer to do things instead of endlessly repeated words.

According to PHPNG - we set one big goal (performance), and worked on it
really hard. Now everyone may see the result. It's just not possible to
solve all the goals at once and we didn't try to do it.

Big PHP users just can't not to care about performance, because it's money.
I know most of them already experimented with HHVM.
If we don't provide adequate replay, we may turn back into the language for
home pages.

Thanks. Dmitry.




On Tue, Jul 22, 2014 at 6:58 AM, Pierre Joye  wrote:

> hi,
>
>
> On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui  wrote:
>
> >> https://wiki.php.net/rfc/uniform_variable_syntax
> >> https://wiki.php.net/rfc/size_t_and_int64_next
> >
> > aren't they discussed and voted? what do you mean by  we can't even
> > start in previous comment?
>
> The int64 yes, that means and it is/was not possible given the status
> of phpng in the last weeks, way too many huge changes.
>
> >>>
> >>> Or you suggest we stop the current work to waiting them come their
> self?
> >>
> >>
> >> I'm saying that we should resolve the current situation where people
> can't
> >> work on stuff which would target php-next, because it is still a moving
> >> target.
> >
> > why Nikita could work on it? why me can work on it?
>
> Who is asking you to work on that?
>
>
> >> I'm saying that it is pretty unfortunate that we have to decide to
> between
> >> reviewing/accepting a huuuge chunk of changes or rejecting a
> significant
> >> performance boost and some api cleanup.
> >
> > we shouldn't,  at least most people here shouldn't,  only the guys who
> > need to maintain them should.
>
> Yes and no. phpng, as a whole, as it was done, as it is done, and as
> it is proposed forces us to this choice.
>
> I have asked very "early" (later on that) about your plans, and it was
> told it will not be the base for php-next and its aim is not to
> replace master. I expressed doubts, I see now that I was right.
>
> >> I'm saying that we should stop pushing our own agendas, and figure out
> the
> >> best possible solution for the current situation, so that we can go
> forward
> >> with the development with the normal workflow, where everybody is on the
> >> same page, controversial changes are done through RFCs and we don't
> block
> >> each other from the work.
> >
> > you know what?  I really don't like "we should; we must", they means
> nothing..
>
>
> They mean a lot, really a lot.
>
> > I have spent lots of my time to work on PHP/PHPNG,  more than 80 hours
> > per month.
>
> Oh very nice. Now what do you think we spend on the int64 patch? While
> you were saying that it is fine for master but rejecting it later on
> because of your secret work on phpng? I really do not like that.
>
> > I treat it like a regular work, dmitry spends more than me(8 hours per
> day).
> >
> > you ask me to stop to wait somebody who even can not work hours a month
> here?
>
> It is called team work, with full time developers (very few) and other
> contributors, doing work on php in their free time (the waste
> majority). We have to respect the latter much more, much much more.
>
> > with all my respects:   I really upset by people who always told you,
> > hey man, don't be rush...
>
> Nobody tells you not to rush to work on a given feature. However many
> did, and I'd to tell it again: do not to rush on pushing the next
> major release. The version we (all) have to maintain for the next
> decade. And by maintain it is not only about the core, it is about its
> extensions, be in core extensions and in PECL or other areas. A bad,
> unclean or broken APIs affect everyone, not only the few maintaining
> only one part of PHP, and only on one single platform. It will also
> affects end users projects, the health of a project affects everyone
> using it.
>
> > because I am rushing,  I have be rushing for months to make the work
> done..
>
> Most part of this work has been done in secret, without discussing
> with anyone but between you guys. While we were talking about our
> plans for php-next, even began the work, you were "rushing" to get
> phpng ready for the announce or release. You did not participate to
> any discussions nor proposed anything, not even mentioning your work
> on phpng. This is not the PHP I want to work with, it never was.
>
> Also rushing does not mean the work get done correctly. It is often
> the contrary. We can see that with phpng, you guys have worked very
> hard, but you worked in a bubble and now you come out of this bubble
> and tell us that it is all you want for next and that we should do it
> within a year. No, sorry, I can't and won't accept that.
>
> > last of all : "all above is my personal comments, has nothing to do
> > with Zend"...
>
> It has a lot to do with Zend given that Zend funds you to work on
> phpng and disallows you to communicate about it un

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread David Soria Parra


Am 7/21/14, 10:21 PM, schrieb Yasuo Ohgaki:

> 
> Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
> any new feature will end up with master, I suppose. If a new feature is 
> only available to PHP-5.7 branch, it's a merge bug, isn't it?
> 
> Regards,

We had this policy before and it didn't help us. The problem is
maintiaining all the branches and keeping people interested in the next
branch because people tend to focus on the currently release branch.
When we decided upon the release RFC we talked a lot about the overhead
of maintaing multiple branches and tried to reduce the amount of
branches. In particular with API changes it becomes tidious if we try to
maintain a feature across branches and that implicit divergence has to
be resolved better sooner or later, or otherwise it would be just like
the old php6 again.

David

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Yasuo Ohgaki
Hi David,

On Tue, Jul 22, 2014 at 2:08 PM, David Soria Parra  wrote:

> On 2014-07-21, Michael Wallner  wrote:
> > --001a11345984e013cd04feb0d9a1
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: quoted-printable
> >
> > On 21 Jul 2014 10:21, "Julien Pauli"  wrote:
> > 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.
>

Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
any new feature will end up with master, I suppose. If a new feature is
only available to PHP-5.7 branch, it's a merge bug, isn't it?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread David Soria Parra
On 2014-07-21, Michael Wallner  wrote:
> --001a11345984e013cd04feb0d9a1
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> On 21 Jul 2014 10:21, "Julien Pauli"  wrote:
> 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Yasuo Ohgaki
Hi Zeev,

On Mon, Jul 21, 2014 at 7:18 PM, Zeev Suraski  wrote:

> Hi Zeev,
>
>
>
> On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski  wrote:
>
> As we’re getting closer to release 5.6.0, and given the very high level of
> interest in phpng, I think it’s time for us to provide some clarity
> regarding what happens post 5.6.0.
>
>
>
> Are you willing to have 5.7 branch?
>
> It gives us more time to develop/cleanup/test. It's especially important
> for
>
> 3rd party module developers.
>
> Can you explain a bit more what you mean by that?  I generally don’t think
> we should invest in another feature release before this next phpng-based
> major version (that’s my personal thinking).  It’ll spread our limited
> resources too thin;  But maybe I didn’t quite understand what you had in
> mind for putting in the 5.7 branch.
>

Sorry that my mail is not precise enough.
I'm not sure your intention if we are going to have master branch as
successor of
PHP 5.6 or not.

If it is PHP 5.6 successor, then we have less than a year before feature
freeze.
If there is PHP 5.7 branch, I suppose we have more than a year before
feature freeze.

I feel less than a year for new major version is too short, so I would like
to have PHP 5.7,
then a year later PHP 6/7. There are too many things that I would like to
cleanup. I'm mainly
interested in userland API cleanups/additions as well as mbstring/session
internal.

Developing 5.7 and 6/7 at the same is beneficial to us, too. We may
implement migration
features in 5.7. 3rd party module developers will have enough time to
migrate before release
also. We may have long alpha period for 6/7. I suppose having 5.7 branch
does not waste
yours and your people's time much if phpng became master.

BTW, I'm in favor of PHP 7.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Pierre Joye
hi,


On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui  wrote:

>> https://wiki.php.net/rfc/uniform_variable_syntax
>> https://wiki.php.net/rfc/size_t_and_int64_next
>
> aren't they discussed and voted? what do you mean by  we can't even
> start in previous comment?

The int64 yes, that means and it is/was not possible given the status
of phpng in the last weeks, way too many huge changes.

>>>
>>> Or you suggest we stop the current work to waiting them come their self?
>>
>>
>> I'm saying that we should resolve the current situation where people can't
>> work on stuff which would target php-next, because it is still a moving
>> target.
>
> why Nikita could work on it? why me can work on it?

Who is asking you to work on that?


>> I'm saying that it is pretty unfortunate that we have to decide to between
>> reviewing/accepting a huuuge chunk of changes or rejecting a significant
>> performance boost and some api cleanup.
>
> we shouldn't,  at least most people here shouldn't,  only the guys who
> need to maintain them should.

Yes and no. phpng, as a whole, as it was done, as it is done, and as
it is proposed forces us to this choice.

I have asked very "early" (later on that) about your plans, and it was
told it will not be the base for php-next and its aim is not to
replace master. I expressed doubts, I see now that I was right.

>> I'm saying that we should stop pushing our own agendas, and figure out the
>> best possible solution for the current situation, so that we can go forward
>> with the development with the normal workflow, where everybody is on the
>> same page, controversial changes are done through RFCs and we don't block
>> each other from the work.
>
> you know what?  I really don't like "we should; we must", they means nothing..


They mean a lot, really a lot.

> I have spent lots of my time to work on PHP/PHPNG,  more than 80 hours
> per month.

Oh very nice. Now what do you think we spend on the int64 patch? While
you were saying that it is fine for master but rejecting it later on
because of your secret work on phpng? I really do not like that.

> I treat it like a regular work, dmitry spends more than me(8 hours per day).
>
> you ask me to stop to wait somebody who even can not work hours a month here?

It is called team work, with full time developers (very few) and other
contributors, doing work on php in their free time (the waste
majority). We have to respect the latter much more, much much more.

> with all my respects:   I really upset by people who always told you,
> hey man, don't be rush...

Nobody tells you not to rush to work on a given feature. However many
did, and I'd to tell it again: do not to rush on pushing the next
major release. The version we (all) have to maintain for the next
decade. And by maintain it is not only about the core, it is about its
extensions, be in core extensions and in PECL or other areas. A bad,
unclean or broken APIs affect everyone, not only the few maintaining
only one part of PHP, and only on one single platform. It will also
affects end users projects, the health of a project affects everyone
using it.

> because I am rushing,  I have be rushing for months to make the work done..

Most part of this work has been done in secret, without discussing
with anyone but between you guys. While we were talking about our
plans for php-next, even began the work, you were "rushing" to get
phpng ready for the announce or release. You did not participate to
any discussions nor proposed anything, not even mentioning your work
on phpng. This is not the PHP I want to work with, it never was.

Also rushing does not mean the work get done correctly. It is often
the contrary. We can see that with phpng, you guys have worked very
hard, but you worked in a bubble and now you come out of this bubble
and tell us that it is all you want for next and that we should do it
within a year. No, sorry, I can't and won't accept that.

> last of all : "all above is my personal comments, has nothing to do
> with Zend"...

It has a lot to do with Zend given that Zend funds you to work on
phpng and disallows you to communicate about it until it is announced
(NDA). It is a shame to have NDAs to work on the core. It is a shame
to come now and say things like "why should we wait for next if we
(zend) are ready?" while having literally blocked everything since the
announce of phpng.

PHP-next is about a lot of things, way behind performance issues. You
care only about that, but I, f.e., do care about performance only for
20% of my priorities. Large PHP users told me the same. The needs,
goals etc for php-next have been discussed and listed. Some of these
todos have been worked on, publically, with periodic communications
about the status, what has been done, etc. Discussing with many
contributors, publicly, openly. This is how it should be. Yes, you do
not like the "should" usage, but I repeat, it must be like that. If we
can work on PHP openly, I fail to understand why Zend tot

Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Xinchen Hui
Hey:

 I really don't like arguing in english, so this will be my last
reply in this thread.

On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs  wrote:
>
>
>
> On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui  wrote:
>>
>> Hey:
>>
>> > 在 2014年7月21日,19:02,Ferenc Kovacs  写道:
>> >
>> >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski  wrote:
>> >>
>> >>
>> >>
>> >> 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
>> >
>> > because there is so much stuff which we want to do in the next major
>> > version, but we can't even start because there is no stable base to
>> > target
>> > the other php-next features.
>> What they are?  Please come with RFC and Patches.
>
>
> https://wiki.php.net/rfc/uniform_variable_syntax
> https://wiki.php.net/rfc/size_t_and_int64_next

aren't they discussed and voted? what do you mean by  we can't even
start in previous comment?
>
>>
>> Or you suggest we stop the current work to waiting them come their self?
>
>
> I'm saying that we should resolve the current situation where people can't
> work on stuff which would target php-next, because it is still a moving
> target.

why Nikita could work on it? why me can work on it?

> I'm saying that it is nice that you(the phpng main devs) are confident that
> you can stabilize your changes so making a php-next release in less than a
> year, but other people have other ideas which can only happen in a major
> version, and you shouldn't rush an early release which would mean that the
> next window of opportunity for major refactor is in the next decade.
I am not sure about you attitude here,  from these words,  seems you
agree to merge phpng to master asap, then people can start work on it?

> I'm saying that it is pretty unfortunate that we have to decide to between
> reviewing/accepting a huuuge chunk of changes or rejecting a significant
> performance boost and some api cleanup.

we shouldn't,  at least most people here shouldn't,  only the guys who
need to maintain them should.

> I'm saying that we should stop pushing our own agendas, and figure out the
> best possible solution for the current situation, so that we can go forward
> with the development with the normal workflow, where everybody is on the
> same page, controversial changes are done through RFCs and we don't block
> each other from the work.

you know what?  I really don't like "we should; we must", they means nothing..

I have spent lots of my time to work on PHP/PHPNG,  more than 80 hours
per month.

I treat it like a regular work, dmitry spends more than me(8 hours per day).

you ask me to stop to wait somebody who even can not work hours a month here?

with all my respects:   I really upset by people who always told you,
hey man, don't be rush...

because I am rushing,  I have be rushing for months to make the work done..

last of all : "all above is my personal comments, has nothing to do
with Zend"...

thanks
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu



-- 
惠新宸laruence
Senior PHP Engineer
http://www.laruence.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Ferenc Kovacs
On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui  wrote:

> Hey:
>
> > 在 2014年7月21日,19:02,Ferenc Kovacs  写道:
> >
> >> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski  wrote:
> >>
> >>
> >>
> >> 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
> >
> > because there is so much stuff which we want to do in the next major
> > version, but we can't even start because there is no stable base to
> target
> > the other php-next features.
> What they are?  Please come with RFC and Patches.
>

https://wiki.php.net/rfc/uniform_variable_syntax
https://wiki.php.net/rfc/size_t_and_int64_next


> Or you suggest we stop the current work to waiting them come their self?
>

I'm saying that we should resolve the current situation where people can't
work on stuff which would target php-next, because it is still a moving
target.
I'm saying that it is nice that you(the phpng main devs) are confident that
you can stabilize your changes so making a php-next release in less than a
year, but other people have other ideas which can only happen in a major
version, and you shouldn't rush an early release which would mean that the
next window of opportunity for major refactor is in the next decade.
I'm saying that it is pretty unfortunate that we have to decide to between
reviewing/accepting a huuuge chunk of changes or rejecting a
significant performance boost and some api cleanup.
I'm saying that we should stop pushing our own agendas, and figure out the
best possible solution for the current situation, so that we can go forward
with the development with the normal workflow, where everybody is on the
same page, controversial changes are done through RFCs and we don't block
each other from the work.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu


Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Pierre Joye
On Mon, Jul 21, 2014 at 5:36 PM, Xinchen Hui  wrote:
>
>
> 发自我的 iPad
>
> 在 2014年7月21日,23:30,Pierre Joye  写道:
>
>
> On Jul 21, 2014 5:28 PM, "Xinchen Hui"  wrote:
>
>> Or you suggest we stop the current work to waiting them come their self?
>
> This is exactly what you have done. So what?
>
> But no, talking for me (and a couple of other), I have listed what I would
> like to see before I even consider something else than -1.
>
> With all respects,   I think you are too strict on phpng

I am not strict but I am realistic, to avoid a total failure with php-next.

> We all hope php to get better, for now I really care about performance

Right, we all care about php. The question is more about how we care
about its future and how to get everyone involved and get PHP cleaner,
better and easier to maintain.

> We are loosing users who switch to hhvm for performance. Phpng will change
> the current embarrasse situation to us

That's not what I see but for very few users. Visibility, cleaner (or
less ugly) code base, better communication with the developers, etc.
are more the points why some moves to hhvm. Some features we rejected
in the past (strict hinting for method/function signature f.e., hack)
are other reasons mentioned very often.

Also keep in mind that I do love the performance improvements brought
by phpng. It is really awesome. And again, thanks you guys for this
effort.

However it is critical, I repeat, critical, to keep other goals in
mind for php-next. You forgot them for the last six months but it is
too late. However if things go like Zend plans, it will be too late,
and we will fail, miserably.

I also talked to many very large PHP users in the last two months. As
they all care about performance, it is not really their issue right
now with php. One reason is that PHP rarely causes actual bottlenecks
in their apps. But they have other worries, one of them is the code
quality of the PHP core, which is by far not as good as it should be
for the leading web programming language. And they expect the next
major version to fix that. Not only to be more confident about the PHP
implementation but also to ease contributions or extensions
implementations. PHPNG solves none of these issues, in contrary.

Cheers,
-- 
Pierre

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Xinchen Hui
Hey:

> 在 2014年7月21日,19:02,Ferenc Kovacs  写道:
>
>> On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski  wrote:
>>
>>
>>
>> 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
>
> because there is so much stuff which we want to do in the next major
> version, but we can't even start because there is no stable base to target
> the other php-next features.
What they are?  Please come with RFC and Patches.

Or you suggest we stop the current work to waiting them come their self?

Thanks
> based on the history of php versions, any feature which misses php-next
> will have to wait for the next decade, so I don't think that we should rush
> it (to meet our yearly release cycle defined in
> https://wiki.php.net/rfc/releaseprocess).
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Xinchen Hui
Hey:

> 在 2014年7月21日,18:56,Pierre Joye  写道:
>
>> On Mon, Jul 21, 2014 at 12:50 PM, Dmitry Stogov  wrote:
>>
>> We thought about it many time, but didn't have time to do it.
>
> cleanup makes code bases smaller, more maintainable, easier to change.
> The time spent to port dead parts of PHP should have been better
> spent. It is too late to do that :)
>
I don't know what kind of cleanup are you talking?  I have spent
months to do that, convert exts, cleanup dead codes, refactor ugly
hacks

If that still not enough, I think we should merge phpng to master
ASAP, then people can help me to do such things.

Thanks
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Pierre Joye
On Mon, Jul 21, 2014 at 4:19 PM, Benjamin Eberlei  wrote:
> On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov  wrote:
>
>> Hi Matteo,
>>
>> We have very limited forces to test everything. Once we we have bug reports
>> we may look into the problems and fix them.
>>
>
> Wouldn't it be super easy to use the HHVM team infrastructure to test a
> version against various PHP projects testsuites? I can't imagine it would
> take longer than a few hours to adjust this to PHPs needs.

Exactly, and we do have a good one too. But if nobody reads it or
nobody cares, we can add as much CI as we want, that won't change
anything.

-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Benjamin Eberlei
On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov  wrote:

> Hi Matteo,
>
> We have very limited forces to test everything. Once we we have bug reports
> we may look into the problems and fix them.
>

Wouldn't it be super easy to use the HHVM team infrastructure to test a
version against various PHP projects testsuites? I can't imagine it would
take longer than a few hours to adjust this to PHPs needs.


>
> Thanks. Dmitry.
>
>
> On Mon, Jul 21, 2014 at 2:07 PM, Matteo Beccati  wrote:
>
> > On 21/07/2014 11:13, Sebastian Bergmann wrote:
> > > 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 :-)
> >
> > I have temporarily re-enabled the phpng jobs on my CI server to assess
> > the current situation.
> >
> > I can confirm that just one test is failing with PHPUnit master. It
> > seems that print_r is not displaying StdClass properties as it used to:
> >
> >
> >
> https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493
> >
> >
> > On the other hand Doctrine master can't even run the entire test suite
> > due to:
> >
> > Fatal error: Call to a member function getConfiguration() on null in
> >
> >
> /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
> > on line 482
> >
> > (pretty sure it's not a null there: a var_dump before the call tells me
> > it's an object)
> >
> > https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log
> >
> >
> > The Revive Adserver test suite fails miserably (86+ out of 274 test
> > files), mostly due to errors like:
> >
> >
> >
> /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
> > : ht=0x29c7aa8 is already destroyed
> >
> > and some "Call to a member function" errors on object variables that are
> > mysteriously seen as null.
> >
> > https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64
> >
> > There's lots of legacy code in there and it has proved to be useful in
> > past to catch a few uncommon segmentation faults. I'm pretty sure that
> > there are plenty other applications that can't work with phpng as it is
> > now.
> >
> > To be honest I don't think we're anywhere near the point where it's safe
> > to merge phpng to master.
> >
> > Also, one thing that might have been overlooked is that merging phpng to
> > master would completely bypass the voting phase on
> > https://wiki.php.net/rfc/fast_zpp
> >
> >
> > Cheers
> > --
> > Matteo Beccati
> >
> > Development & Consulting - http://www.beccati.com/
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>


RE: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Derick Rethans
On Mon, 21 Jul 2014, Zeev Suraski wrote:

> From: Andrea Faulds [mailto:a...@ajf.me]
> >
> > We *could* make PHP NEXT in a year, sure, but it won't be worthwhile 
> > being called PHP NEXT.
> 
> Everything I know about the PHP community, combined with the amazing 
> level of interest that the recent PHPNG benchmarks garnered, tells me 
> that it wrong.
> People would love to get it even if it was just the performance & 
> memory footprint gains alone.  And we're not even talking about that - 
> we'd still have ample time to put in additional features into it.
> 
> > 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.
> 
> Three years is a lifetime in our world of software...
> 
> > However, I am confident that we need more than a year to make this 
> > major worth it.
> 
> Even if it's going to be 18 months (which is on the upper limit of 
> what I think we should allow for .NEXT), I don't see a need for 5.7 in 
> between. When we created the release process RFC, from the get go, I 
> thought that releasing every 12 months is too frequent.  I was told 
> not to worry and that we'll "see how it goes" and "change if we need 
> to".  Now, suddenly this became a God-given commandment, that we must 
> have a mini version every year and on time - and it's not.  Reality is 
> that the userbase is embracing versions a lot slower than we crank 
> them up - releasing 5.7 to be followed shortly by 6/7 doesn't make a 
> lot of sense, I think.
> 
> Still, I think we're much better off delivering .NEXT as soon as we 
> can as.

I think that's the cru - and very important. I would totally be in 
favour with PHP 7 be "just" PHPNG - as long of course it's finished. 
Whether this takes slightly more than a year, I don't really care.

> > > 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.
> 
> I can live with that, as long as we treat 5.7 as a secondary project 
> where we backport stuff rom master, and as long as it's clear to 
> everyone that it may be (or IMHO may very well be) throw-away code 
> that we'll never actually use.  Personally I think it makes more sense 
> to focus on getting .NEXT out the door quickly so that we don't have 
> to get into the headache of working on two active trees, though.  I'd 
> like to see what others are thinking...

I agree. We should not focus on two active trees.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Matteo Beccati
On 21/07/2014 12:41, Dmitry Stogov wrote:
> Hi Matteo,
> 
> We have very limited forces to test everything. Once we we have bug reports
> we may look into the problems and fix them.

I've been trying to help with testing and reporting on IRC the results.
I think I've mentioned Doctrine a few times already too (on bugs.php.net
phpng is missing in the version field).

What's the best way to report issues, especially if they show up when
running large test suites and it's not possible to create small
self-contained snippets?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Pierre Joye
On Mon, Jul 21, 2014 at 3:47 PM, Zeev Suraski  wrote:
d PHP NEXT.
>
> Everything I know about the PHP community, combined with the amazing level
> of interest that the recent PHPNG benchmarks garnered, tells me that it
> wrong.

You needed one year+ to stabilize opcache, how long will you need for
something as huge as phpng? Along with giving the chance to other to
actually do what we expect in the next major version? In my book it is
more than a year, and between two and three years is a reasonable
timeframe.

> People would love to get it even if it was just the performance & memory
> footprint gains alone.  And we're not even talking about that - we'd still
> have ample time to put in additional features into it.

People tells me something else. But we surely speak to totally different people.


>> 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.
>
> Three years is a lifetime in our world of software...

Are nothing.


> Even if it's going to be 18 months (which is on the upper limit of what I
> think we should allow for .NEXT), I don't see a need for 5.7 in between.

It is per se defined to have a 5.7 next year. I do not see how it
could be remotely possible to have php-next ready by June 2015, except
if you release something not ready and did the same that we did before
"we will fix/clean that later", which indeed never happened.

> When we created the release process RFC, from the get go, I thought that
> releasing every 12 months is too frequent.  I was told not to worry and
> that we'll "see how it goes" and "change if we need to".

We can adapt the RFC, not let a company adapts it as they wish as you
seems to like to do.

>  Now, suddenly
> this became a God-given commandment, that we must have a mini version
> every year and on time - and it's not.  Reality is that the userbase is
> embracing versions a lot slower than we crank them up - releasing 5.7 to
> be followed shortly by 6/7 doesn't make a lot of sense, I think.

Adoption of new versions is increasing, drastically, because of the
release process RFC. That is what many major big companies using PHP
tell me as well as what the numbers I can see tell me.

> Still, I think we're much better off delivering .NEXT as soon as we can
> as.

As soon as we can? Hell yeah. I cannot agree more here. And as soon as
we can is not as soon as you wish or as soon as you consider phpng
release ready (in theory).


>> > 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.
>
> I can live with that, as long as we treat 5.7 as a secondary project where
> we backport stuff rom master, and as long as it's clear to everyone that
> it may be (or IMHO may very well be) throw-away code that we'll never
> actually use.  Personally I think it makes more sense to focus on getting
> .NEXT out the door quickly so that we don't have to get into the headache
> of working on two active trees, though.  I'd like to see what others are
> thinking...

I have no issue working with many trees, CIs get better every day,
testing PRs are now automated, travis support for more platforms is
coming, everything coming together to increase php and related
projects quality.

Cheers,
-- 
Pierre

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Andrea Faulds

On 21 Jul 2014, at 14:47, Zeev Suraski  wrote:

> Everything I know about the PHP community, combined with the amazing level
> of interest that the recent PHPNG benchmarks garnered, tells me that it
> wrong.
> People would love to get it even if it was just the performance & memory
> footprint gains alone.  And we're not even talking about that - we'd still
> have ample time to put in additional features into it.

Yes, “additional” features. Not big ones. That is my point of contention: if 
the only major engine-level thing we have time to add is phpng’s performance 
improvements, I’m not sure it’s worthy of being PHP NEXT.

>>> 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.
> 
> I can live with that, as long as we treat 5.7 as a secondary project where
> we backport stuff rom master, and as long as it's clear to everyone that
> it may be (or IMHO may very well be) throw-away code that we'll never
> actually use.  Personally I think it makes more sense to focus on getting
> .NEXT out the door quickly so that we don't have to get into the headache
> of working on two active trees, though.  I'd like to see what others are
> thinking…

Well, I don’t think that, realistically, introducing PHP NEXT will immediately 
kill the 5.x line. We should have at least one more release after NEXT comes 
out. That release will probably be 5.7, and who knows, perhaps it might 
actually come out *after* NEXT.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Zeev Suraski
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Monday, July 21, 2014 4:10 PM
> To: Zeev Suraski
> Cc: Nikita Popov; PHP internals
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
>
> We *could* make PHP NEXT in a year, sure, but it won't be worthwhile
being
> called PHP NEXT.

Everything I know about the PHP community, combined with the amazing level
of interest that the recent PHPNG benchmarks garnered, tells me that it
wrong.
People would love to get it even if it was just the performance & memory
footprint gains alone.  And we're not even talking about that - we'd still
have ample time to put in additional features into it.

> 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.

Three years is a lifetime in our world of software...

> However, I
> am confident that we need more than a year to make this major worth it.

Even if it's going to be 18 months (which is on the upper limit of what I
think we should allow for .NEXT), I don't see a need for 5.7 in between.
When we created the release process RFC, from the get go, I thought that
releasing every 12 months is too frequent.  I was told not to worry and
that we'll "see how it goes" and "change if we need to".  Now, suddenly
this became a God-given commandment, that we must have a mini version
every year and on time - and it's not.  Reality is that the userbase is
embracing versions a lot slower than we crank them up - releasing 5.7 to
be followed shortly by 6/7 doesn't make a lot of sense, I think.

Still, I think we're much better off delivering .NEXT as soon as we can
as.

> > 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.

I can live with that, as long as we treat 5.7 as a secondary project where
we backport stuff rom master, and as long as it's clear to everyone that
it may be (or IMHO may very well be) throw-away code that we'll never
actually use.  Personally I think it makes more sense to focus on getting
.NEXT out the door quickly so that we don't have to get into the headache
of working on two active trees, though.  I'd like to see what others are
thinking...

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Pierre Joye
On Mon, Jul 21, 2014 at 3:06 PM, Zeev Suraski  wrote:

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] RFC: Move phpng to master

2014-07-21 Thread Andrea Faulds

On 21 Jul 2014, at 14:06, Zeev Suraski  wrote:

> 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/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



  1   2   >