HHVM vs. Zend divergence

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

HHVM vs. Zend divergence

Max Semenik
Today, the HHVM developers made an announcement[1] that they have plans of
ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
instead.

While this does not mean that we need to take an action immediately,
eventually we will have to decide something. As I see it, our options are:

1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
PHP. This, however, is a dead end and will make things progressively harder
as the implementations will diverge and various Composer libraries we use
will start requiring some Zend-specific features.

2) Declare our loyalty to HHVM. This will result in most of our current
users being unable to upgrade, eventually producing what amounts to a
WMF-only product and lots of installations with outdated MediaWiki having
security holes. At least we will be able to convert to Hack eventually.
This is a very clean-cut case of vendor lock-in though, and if Facebook
decides to switch their code base to something shinier, we'll be deep in
trouble.

3) Revert WMF to Zend and forget about HHVM. This will result in
performance degradation, however it will not be that dramatic: when we
upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
5.6 and 7 provided nice performance improvements.

I personally think that 3) is the only viable option in the long run. What
do you think?

----
[1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html

--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

James Hare-4
On Sep 18, 2017, at 1:58 PM, Max Semenik <[hidden email]> wrote:

>
> Today, the HHVM developers made an announcement[1] that they have plans of
> ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> instead.
>
> While this does not mean that we need to take an action immediately,
> eventually we will have to decide something. As I see it, our options are:
>
> 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
> PHP. This, however, is a dead end and will make things progressively harder
> as the implementations will diverge and various Composer libraries we use
> will start requiring some Zend-specific features.
>
> 2) Declare our loyalty to HHVM. This will result in most of our current
> users being unable to upgrade, eventually producing what amounts to a
> WMF-only product and lots of installations with outdated MediaWiki having
> security holes. At least we will be able to convert to Hack eventually.
> This is a very clean-cut case of vendor lock-in though, and if Facebook
> decides to switch their code base to something shinier, we'll be deep in
> trouble.
>
> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
> 5.6 and 7 provided nice performance improvements.

Do we have performance benchmarks on 5.3 vs. HHVM vs. 5.6 vs. 7?

>
> I personally think that 3) is the only viable option in the long run. What
> do you think?
>
> ----
> [1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Paladox
 I think option 2 will be impossible. As that will decrease the user base of mediawiki by a lot.
I think we should go with option 3 as php 7 has had increased in performances.    On Monday, 18 September 2017, 22:03:20 BST, James Hare <[hidden email]> wrote:  
 
 On Sep 18, 2017, at 1:58 PM, Max Semenik <[hidden email]> wrote:

>
> Today, the HHVM developers made an announcement[1] that they have plans of
> ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> instead.
>
> While this does not mean that we need to take an action immediately,
> eventually we will have to decide something. As I see it, our options are:
>
> 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
> PHP. This, however, is a dead end and will make things progressively harder
> as the implementations will diverge and various Composer libraries we use
> will start requiring some Zend-specific features.
>
> 2) Declare our loyalty to HHVM. This will result in most of our current
> users being unable to upgrade, eventually producing what amounts to a
> WMF-only product and lots of installations with outdated MediaWiki having
> security holes. At least we will be able to convert to Hack eventually.
> This is a very clean-cut case of vendor lock-in though, and if Facebook
> decides to switch their code base to something shinier, we'll be deep in
> trouble.
>
> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
> 5.6 and 7 provided nice performance improvements.

Do we have performance benchmarks on 5.3 vs. HHVM vs. 5.6 vs. 7?

>
> I personally think that 3) is the only viable option in the long run. What
> do you think?
>
> ----
> [1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

C. Scott Ananian
In reply to this post by Max Semenik
On Mon, Sep 18, 2017 at 4:58 PM, Max Semenik <[hidden email]> wrote:

> security holes. At least we will be able to convert to Hack eventually.
> This is a very clean-cut case of vendor lock-in though, and if Facebook
> decides to switch their code base to something shinier, we'll be deep in
> trouble.
>

I actually predicted this and wrote up my suggestions here:
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Writing_Tips/Examples#Example_of_a_.22medium_level.22_position_statement

I will *not* be making this my position statement at the dev summit -- only
one per person, so many positions to take, this one didn't make the cut! --
but I would like to strongly encourage someone to submit a position
statement relating to this issue (could be any of max's three positions) to
the dev summit.  I think it is an important issue for our foundation and
community to discuss; certainly very relevant to the next 15 years of the
project.
  --scott
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Brad Jorsch (Anomie)
In reply to this post by Max Semenik
On Mon, Sep 18, 2017 at 4:58 PM, Max Semenik <[hidden email]> wrote:

> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated,
> while 5.6 and 7 provided nice performance improvements.
>

In particular, I've heard good things about PHP 7 performance. Someone less
lazy than I am at 5pm might want to do some research on that though.

I can say that PHP 7 locally runs unit tests significantly faster than PHP
5.6, although that's not really a representative workload for running a
website.


--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Brian Wolff
In reply to this post by Max Semenik
On Monday, September 18, 2017, Max Semenik <[hidden email]> wrote:
> Today, the HHVM developers made an announcement[1] that they have plans of
> ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> instead.
>
> While this does not mean that we need to take an action immediately,
> eventually we will have to decide something. As I see it, our options are:
>
> 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
> PHP. This, however, is a dead end and will make things progressively
harder

> as the implementations will diverge and various Composer libraries we use
> will start requiring some Zend-specific features.
>
> 2) Declare our loyalty to HHVM. This will result in most of our current
> users being unable to upgrade, eventually producing what amounts to a
> WMF-only product and lots of installations with outdated MediaWiki having
> security holes. At least we will be able to convert to Hack eventually.
> This is a very clean-cut case of vendor lock-in though, and if Facebook
> decides to switch their code base to something shinier, we'll be deep in
> trouble.
>
> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated,
while

> 5.6 and 7 provided nice performance improvements.
>
> I personally think that 3) is the only viable option in the long run. What
> do you think?
>
> ----
> [1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Well i agree that 3 seems likely the best long term option, we will
probably be doing 1 in the short term. However I think it would be prudent
to wait and see how things turn out in the short term before comitting to
any path. The landscape can still shift quite a lot before the time comes
when its impractical to continue doing 1.

--
bawolff
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

C. Scott Ananian
Other tools we are using, such as Phabricator, will also be following HHVM
to Hack (presumably).  Facebook, as the largest (by engineering budget)
production user of PHP, will certainly have an outsized influence on the
direction of the platform and surrounding ecosystem.  If we follow path #3
we're probably also committing to supporting Zend development long-term as
the primary production user.
  --scott

On Mon, Sep 18, 2017 at 5:26 PM, Brian Wolff <[hidden email]> wrote:

> On Monday, September 18, 2017, Max Semenik <[hidden email]> wrote:
> > Today, the HHVM developers made an announcement[1] that they have plans
> of
> > ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> > instead.
> >
> > While this does not mean that we need to take an action immediately,
> > eventually we will have to decide something. As I see it, our options
> are:
> >
> > 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
> > PHP. This, however, is a dead end and will make things progressively
> harder
> > as the implementations will diverge and various Composer libraries we use
> > will start requiring some Zend-specific features.
> >
> > 2) Declare our loyalty to HHVM. This will result in most of our current
> > users being unable to upgrade, eventually producing what amounts to a
> > WMF-only product and lots of installations with outdated MediaWiki having
> > security holes. At least we will be able to convert to Hack eventually.
> > This is a very clean-cut case of vendor lock-in though, and if Facebook
> > decides to switch their code base to something shinier, we'll be deep in
> > trouble.
> >
> > 3) Revert WMF to Zend and forget about HHVM. This will result in
> > performance degradation, however it will not be that dramatic: when we
> > upgraded, we switched to HHVM from PHP 5.3 which was really outdated,
> while
> > 5.6 and 7 provided nice performance improvements.
> >
> > I personally think that 3) is the only viable option in the long run.
> What
> > do you think?
> >
> > ----
> > [1] http://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
> >
> > --
> > Best regards,
> > Max Semenik ([[User:MaxSem]])
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> Well i agree that 3 seems likely the best long term option, we will
> probably be doing 1 in the short term. However I think it would be prudent
> to wait and see how things turn out in the short term before comitting to
> any path. The landscape can still shift quite a lot before the time comes
> when its impractical to continue doing 1.
>
> --
> bawolff
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--
(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Max Semenik
On Mon, Sep 18, 2017 at 2:33 PM, C. Scott Ananian <[hidden email]>
wrote:

> Other tools we are using, such as Phabricator, will also be following HHVM
> to Hack (presumably).


To the contrary, Phabricator has never supported HHVM.

--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Stas Malyshev
In reply to this post by Max Semenik
Hi!

> 1) Continue requiring that MediaWiki uses a common set of HHVM and Zend
> PHP. This, however, is a dead end and will make things progressively harder
> as the implementations will diverge and various Composer libraries we use
> will start requiring some Zend-specific features.

This will probably ultimately happen, but given the PHP version stats,
e.g. here:
https://seld.be/notes/php-versions-stats-2017-1-edition

I think we have several years at least before that starts becoming an
issue. Realistically, if you write distributable PHP code now, targeting
7.1 gets you only 17% of the users, so you'd do either 7.0 (gets you
about half) or more likely even 5.6. Extending this trend (I know,
dangerous, but let's assume) if 7.2 is released somewhere around Dec
2017-Jan 2018, 7.3 would probably not happen before around 2019. If that
would have features not supported in HHVM, that means we'd have to worry
around 2021 when people would start releasing components targeting it.
So we have about 3 years to get the solution - *if* 7.3 has features not
supported by HHVM.

Note that this statistics is for Composer users, which means it is
probably skewed towards modern versions, since people using PHP 5.3
probably don't use Composer too much in general. OTOH, since we do use
Composer, that appears to be appropriate for our case.

> 2) Declare our loyalty to HHVM. This will result in most of our current
> users being unable to upgrade, eventually producing what amounts to a
> WMF-only product and lots of installations with outdated MediaWiki having
> security holes. At least we will be able to convert to Hack eventually.
> This is a very clean-cut case of vendor lock-in though, and if Facebook
> decides to switch their code base to something shinier, we'll be deep in
> trouble.

I don't think this is a good idea, for reasons that seem obvious to me
(but I can elaborate if necessary).

> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
> 5.6 and 7 provided nice performance improvements.

I think we should evaluate 7.1 or 7.2 (provided we don't have any
runtime issues with them) and see how performance looks like ASAP (with
opcache, of course). Of there's some help needed, or there are some
specific issues that are blockers, I think Zend team would be glad to
talk to us. If needed, I could probably help with establishing the
contacts.
--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Stas Malyshev
In reply to this post by C. Scott Ananian
Hi!

> Other tools we are using, such as Phabricator, will also be following HHVM
> to Hack (presumably).  

I am not sure this is the case. Mozilla recently declared they want to
use Phabricator[1], but I heard no mention about HHVM. Which makes me
think that one stays on PHP. Also, Phabricator is now independent from
Facebook, afaik, since it's developers have separate company, Phacility.

[1] https://wiki.mozilla.org/Phabricator

--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Stas Malyshev
In reply to this post by Brad Jorsch (Anomie)
Hi!

> I can say that PHP 7 locally runs unit tests significantly faster than PHP
> 5.6, although that's not really a representative workload for running a
> website.

PHP 7 is faster than 5.6, and probably be on almost any workload, from
my experience (the degree of speedup would vary of course). As for
comparison with hhvm, I heard various reports, but I think spending some
time on seriously testing it (I mean creating proper production setup,
and directing either captured/replayed or real traffic to it) is the
best way to go.
--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Jeroen De Dauw-2
In reply to this post by Max Semenik
Hey,

Going with option 2 would be a rather big f***-*** to the non-WMF part of
the MediaWiki community. Furthermore, it would limit usage of common PHP
libraries, which sooner or later will end up using features not available
in HHVM. This, together with the already outlined reasons, makes me concur
with HHVM not being a viable long term option.

If only WMF was running PHP 7.1 already... guess I'll have more luck asking
for a pony though :)

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw
Software craftsmanship advocate
~=[,,_,,]:3
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Tim Starling-2
In reply to this post by Max Semenik
On 19/09/17 06:58, Max Semenik wrote:
> Today, the HHVM developers made an announcement[1] that they have plans of
> ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> instead.

The HHVM team did tell us privately that they were planning on
changing their strategy, basically as you describe it above. The
surprising things for me in this announcement were:

* The plan to also drop PHP 5 compatibility, on a short timeline (1 year).
* Rather than "drifting away" from PHP, their top priority plans
include removing core language features like references and destructors.

> While this does not mean that we need to take an action immediately,
> eventually we will have to decide something.

Actually, I think a year is a pretty short time for ops to switch to
PHP 7. I think we need to decide on this pretty much immediately.

> 3) Revert WMF to Zend and forget about HHVM. This will result in
> performance degradation, however it will not be that dramatic: when we
> upgraded, we switched to HHVM from PHP 5.3 which was really outdated, while
> 5.6 and 7 provided nice performance improvements.
>
> I personally think that 3) is the only viable option in the long run. What
> do you think?

Yes, I think it's the only viable option.

I'll run a benchmark, but I don't see how it could influence the
decision. It'll be more for capacity planning.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Stas Malyshev
Hi!

> * Rather than "drifting away" from PHP, their top priority plans
> include removing core language features like references and destructors.

Wow. I can see why they're doing it (those are sources of most
complications ans security issues in the language, references being
especially weird and tricky). But dropping those would certainly mean
very heavy incompatibility with PHP, by which point it'd be completely
separate language. Which probably excludes Max's #2 from consideration
altogether.

> Actually, I think a year is a pretty short time for ops to switch to
> PHP 7. I think we need to decide on this pretty much immediately.

Should it be on the TechCom agenda and should we have some public
discussion on IRC in RFC format for this soon?

--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Chad
On Mon, Sep 18, 2017 at 5:44 PM Stas Malyshev <[hidden email]>
wrote:

> Hi!
>
> > * Rather than "drifting away" from PHP, their top priority plans
> > include removing core language features like references and destructors.
>
> Wow. I can see why they're doing it (those are sources of most
> complications ans security issues in the language, references being
> especially weird and tricky). But dropping those would certainly mean
> very heavy incompatibility with PHP, by which point it'd be completely
> separate language. Which probably excludes Max's #2 from consideration
> altogether.
>
> > Actually, I think a year is a pretty short time for ops to switch to
> > PHP 7. I think we need to decide on this pretty much immediately.
>
> Should it be on the TechCom agenda and should we have some public
> discussion on IRC in RFC format for this soon?
>
>
I see zero reason for us to go through all the formalities, unless we want
to really. I have yet to see anyone (on list, or on IRC anywhere at all
today) where anyone suggested (2) was a good idea at all. It's a
horrifically bad idea. I don't consider it remotely viable and would do
everything possible to veto such a move.

(1) is impossible as a long-term goal.

So this basically means we're going the route of (3) which is the only way
we can actually expect people to use MediaWiki outside of Wikimedia. And
considering we never really implemented any HHVM/Hack specific features (as
far as I know) it means there's no reason we have to continue to support
HHVM at all once WMF has moved off of it.

It's been a fun experiment for the past couple of years, but it's time to
move on.

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Legoktm
In reply to this post by Tim Starling-2
Hi,

On 09/18/2017 05:13 PM, Tim Starling wrote:
> * The plan to also drop PHP 5 compatibility, on a short timeline (1 year).
> * Rather than "drifting away" from PHP, their top priority plans
> include removing core language features like references and destructors.

On Reddit[1], a member of the HHVM team clarified they plan on dropping
support for destructors *from Hack* soon. (Not that I think it really
makes any difference in what our long-term plan should be.)

[1] https://www.reddit.com/r/PHP/comments/70wtky/the_future_of_hhvm/dn6skdn/

-- Legoktm

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Tim Starling-2
On 19/09/17 12:30, Legoktm wrote:

> Hi,
>
> On 09/18/2017 05:13 PM, Tim Starling wrote:
>> * The plan to also drop PHP 5 compatibility, on a short timeline (1 year).
>> * Rather than "drifting away" from PHP, their top priority plans
>> include removing core language features like references and destructors.
>
> On Reddit[1], a member of the HHVM team clarified they plan on dropping
> support for destructors *from Hack* soon. (Not that I think it really
> makes any difference in what our long-term plan should be.)

It's unclear how much difference that will make, since they are clear
about wanting to make HHVM be purely a Hack runtime. They'll carry on
supporting Composer and PHPUnit, but only until Hack has "its own
ecosystem of core frameworks".

They "will not be targeting PHP software beyond such libraries after
the 3.24 release", which presumably means that they will no longer run
MediaWiki or PHP unit tests against HHVM.

Also, they said that they want to remove destructors in order to
eliminate the performance overhead of reference counting, and I don't
think it is possible to get that performance benefit unless you remove
reference counts from the VM entirely. Maybe removing them from the
Hack language will be a first step, but we can't expect them to keep
them in the VM in the longer term.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Moritz Muhlenhoff
In reply to this post by Tim Starling-2
On Tue, Sep 19, 2017 at 10:13:47AM +1000, Tim Starling wrote:

> On 19/09/17 06:58, Max Semenik wrote:
> > Today, the HHVM developers made an announcement[1] that they have plans of
> > ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> > instead.
>
> The HHVM team did tell us privately that they were planning on
> changing their strategy, basically as you describe it above. The
> surprising things for me in this announcement were:
>
> * The plan to also drop PHP 5 compatibility, on a short timeline (1 year).
> * Rather than "drifting away" from PHP, their top priority plans
> include removing core language features like references and destructors.
>
> > While this does not mean that we need to take an action immediately,
> > eventually we will have to decide something.
>
> Actually, I think a year is a pretty short time for ops to switch to
> PHP 7. I think we need to decide on this pretty much immediately.

The next step would be the upgrade of the mw* fleet to Debian stretch
while still using HHVM 3.18 (to minimise disruption since we've stabilised
3.18 in it's current build). That work is tracked at T174431. 3.18 will
be supported by upstream for at least another six months (and if the migration drags
further I can roll custom 3.18 security backports from later LTS releases)

Debian stretch ships PHP7, so that'd be a good stepstone to migrate
back to Zend.

Cheers,
        Moritz

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Gilles Dubuc
Should we have a TechComm-driven meeting about this ASAP?

Like others, I don't expect that there will be disagreement about the way
to go, but there is a lot to discuss about what needs to be done,
resourcing, etc.

It would be nice to have Ori around for it, to pick his brains about any
undocumented or little-known knowledge about the HHVM migration that could
bite us when migrating to PHP 7.x if we don't know about it.

On Tue, Sep 19, 2017 at 9:07 AM, Moritz Muehlenhoff <
[hidden email]> wrote:

> On Tue, Sep 19, 2017 at 10:13:47AM +1000, Tim Starling wrote:
> > On 19/09/17 06:58, Max Semenik wrote:
> > > Today, the HHVM developers made an announcement[1] that they have
> plans of
> > > ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
> > > instead.
> >
> > The HHVM team did tell us privately that they were planning on
> > changing their strategy, basically as you describe it above. The
> > surprising things for me in this announcement were:
> >
> > * The plan to also drop PHP 5 compatibility, on a short timeline (1
> year).
> > * Rather than "drifting away" from PHP, their top priority plans
> > include removing core language features like references and destructors.
> >
> > > While this does not mean that we need to take an action immediately,
> > > eventually we will have to decide something.
> >
> > Actually, I think a year is a pretty short time for ops to switch to
> > PHP 7. I think we need to decide on this pretty much immediately.
>
> The next step would be the upgrade of the mw* fleet to Debian stretch
> while still using HHVM 3.18 (to minimise disruption since we've stabilised
> 3.18 in it's current build). That work is tracked at T174431. 3.18 will
> be supported by upstream for at least another six months (and if the
> migration drags
> further I can roll custom 3.18 security backports from later LTS releases)
>
> Debian stretch ships PHP7, so that'd be a good stepstone to migrate
> back to Zend.
>
> Cheers,
>         Moritz
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: HHVM vs. Zend divergence

Victoria Coleman
Sounds like a good idea. +Daniel for scheduling.

Best,

Victoria


> On Sep 19, 2017, at 6:56 AM, Gilles Dubuc <[hidden email]> wrote:
>
> Should we have a TechComm-driven meeting about this ASAP?
>
> Like others, I don't expect that there will be disagreement about the way
> to go, but there is a lot to discuss about what needs to be done,
> resourcing, etc.
>
> It would be nice to have Ori around for it, to pick his brains about any
> undocumented or little-known knowledge about the HHVM migration that could
> bite us when migrating to PHP 7.x if we don't know about it.
>
> On Tue, Sep 19, 2017 at 9:07 AM, Moritz Muehlenhoff <
> [hidden email]> wrote:
>
>> On Tue, Sep 19, 2017 at 10:13:47AM +1000, Tim Starling wrote:
>>> On 19/09/17 06:58, Max Semenik wrote:
>>>> Today, the HHVM developers made an announcement[1] that they have
>> plans of
>>>> ceasing to maintain 100% PHP7 compatibility and concentrating on Hack
>>>> instead.
>>>
>>> The HHVM team did tell us privately that they were planning on
>>> changing their strategy, basically as you describe it above. The
>>> surprising things for me in this announcement were:
>>>
>>> * The plan to also drop PHP 5 compatibility, on a short timeline (1
>> year).
>>> * Rather than "drifting away" from PHP, their top priority plans
>>> include removing core language features like references and destructors.
>>>
>>>> While this does not mean that we need to take an action immediately,
>>>> eventually we will have to decide something.
>>>
>>> Actually, I think a year is a pretty short time for ops to switch to
>>> PHP 7. I think we need to decide on this pretty much immediately.
>>
>> The next step would be the upgrade of the mw* fleet to Debian stretch
>> while still using HHVM 3.18 (to minimise disruption since we've stabilised
>> 3.18 in it's current build). That work is tracked at T174431. 3.18 will
>> be supported by upstream for at least another six months (and if the
>> migration drags
>> further I can roll custom 3.18 security backports from later LTS releases)
>>
>> Debian stretch ships PHP7, so that'd be a good stepstone to migrate
>> back to Zend.
>>
>> Cheers,
>>        Moritz
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123