Possible tasks blocking running MediaWiki in production in 5.6-compatible environments:

• Convert mwscript hosts to run on Zend 5.6, not 5.5 – or T146285: Switch mwscript from Zend PHP5 to default php alternative (e.g. HHVM or PHP7)?
• Convert dumps hosts to run on Zend 5.6, not 5.5 – or T94277: Convert snapshot hosts to use HHVM and trusty?
• Convert wikitech host (silver) to run on Zend 5.6, not 5.5 – or T98813: Move wikitech (silver) to HHVM?

I plan to have the dumps hosts upgraded long before this deadline approaches.

Last Call: as per the RFC discussion on IRC on October 18[1], this enters the Last Call period. If no pertinent concerns remain unaddressed by November 1st, this RFC will be approved fro implementation.

Note that this replaced the RFC originally proposed as T172165, which was updated to refer to 1.32 instead of 1.31 now. The discussion about T172165: Require either PHP 7.0+ or HHVM in MW 1.31 has been pushed back for now.

[1] https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.html

+1 to 5.6.

CI side i belive we can go with 5.6+ as hashar removed trusty :).

For CI I ported Zend PHP 5.5 to Jessie which was a rather messy process. But at least we still enforce 5.5 compatibility.

I was hoping MediaWiki LTS 1.31 (EOL June 2021) to switch to PHP7.0. That would have saved CI from having to drag PHP 5.6 for the next four years. At least Debian stretch is supported until 2022. So I guess it is all about porting PHP 5.6 to stretch and we will be fine.

As for adding PHP 5.6 immediately to CI, it is available in Jessie. So it is probably not too much work. But please make sure CI is ready before switching! 😺

Full PHP7 support in CI is a work in progress. It depends on setting up the infrastructure based on Docker containers (and thus replacing Nodepool).

Reading the minutes: I understand changing to PHP 7 is quite a challenge, and it is probably unlikely we would have migrated the Wikimedia cluster to it by the time we cut MediaWiki 1.31.

As far as CI is concerned, I am fine with the outcome of 1.31 sticking to 5.6. Thank you for the last call and the minutes!

See T172165#3699606 for some relevant criticism of this decision.

Continuing from T178538#3699577, the Last Call period for this RFC has expired and TechCom has decided to cancel it's proposed "Approval" based on the new feedback from @Anomie.

At the point of the last IRC discussion about T172165 (Require PHP 7 for MediaWiki), there were various concerns. Including:

• Wikimedia still has various production services running PHP 5.5 or PHP 5.6. (Wikitech, dumps, and some others)
• Even on the main MediaWiki app servers, we use Zend PHP (5.6) for maintenance scripts. (T146285)
• HHVM's "full" PHP7 mode has issues. And switching Wikimedia production to Zend PHP 7 would take more than one year.

For those reasons, we proposed to instead first require PHP 5.6 (T178538#3699577). During the Last Call period, @Anomie wrote an interesting alternate proposal at T172165#3699606:

In T172165#3699606, @Anomie wrote:

HHVM supposedly[1] supports most new php7 features even in php5 mode. The exceptions are 7 changes where php7 broke compatibility with php5, listed at T173786#3651007.

We could support the intersection of php 7.0 and relatively-recent-hhvm-in-php5-mode and be able to use many php7 feature [..]

[1]: I say "supposedly" because there may be bugs, as there are in one of those seven php7 features that has to be explicitly enabled.

In other words, we could raise the requirement from "PHP 5.5+ or compatible" to "Zend PHP 7.0+ or HHVM 3.18+" where we, through social convention, would restrict ourselves to only adopting the subset of new PHP 7 features that are supported by both Zend PHP 7.0+ and HHVM's default mode.

Specifically, we are talking about HHVM's default mode (aka the "php5" mode), not the experimental "php7" mode. This is possible because HHVM actually exposes many of the stable PHP 7 features through its default mode. Only the unstable features or breaking changes from PHP 7 are behind the feature flag.

This raises the following points that would need to be addressed:

• Verify the hypothesis. Ensure MediaWiki works and tests pass under the proposed HHVM version and configuration.
• Document the subset of features we could adopt (Note: this is not the where we discuss whether to use them, just whether we can, technically.)
• Determine whether this can be statically ensured and verified in CI.
• Determine whether Ops can feasibly phase out both PHP 5.5 and PHP 5.6 services within the coming months. (As opposed to just phasing out the PHP 5.5 services)

Does this proposal mean we'd have to migrate all PHP 5.x services to hhvm, with knowledge that we'll have to migrate them to PHP 7 at some later point? Or do we migrate them to PHP 7, while leaving production on HHVM?

In T178538#3728041, @Smalyshev wrote:

Does this proposal mean we'd have to migrate all PHP 5.x services to hhvm, with knowledge that we'll have to migrate them to PHP 7 at some later point? Or do we migrate them to PHP 7, while leaving production on HHVM?

I suppose we could do either. Would be up to opsen what they like better.

In T178538#3728041, @Smalyshev wrote:

Does this proposal mean we'd have to migrate all PHP 5.x services to hhvm, with knowledge that we'll have to migrate them to PHP 7 at some later point? Or do we migrate them to PHP 7, while leaving production on HHVM?

This proposal does not indicate a preference for HHVM. Either HHVM or PHP 7 is fine from this RFC's perspective. Ops can make the call there.

Personally, I can see either's benefits. Moving to PHP 7 directly seems more efficient. On the other hand, it might be significantly easier and less controversial to install HHVM on a server, compared to upgrading an entire base image just to get PHP 7. (Assuming we won't back-port PHP 7, to Trusty or Jessie)

I will note, however, that in the particular case of app servers and MediaWiki cron scripts, there have been issues with using HHVM. So assuming T146285 is still an active issue, it seems that, unless we can fix T146285 soon, we probably can't move to "HHVM/PHP 7" regardless, given that this alternate proposals depends on "Ops may need to upgrade a small number of servers" which would turn into "Ops need to upgrade all app servers to Stretch/PHP7", at which point HHVM would become extinct, and this task redundant.

Stop forcing php5 in mwscript (https://gerrit.wikimedia.org/r/#/c/358896/). Well we just have to do the switch and see what happens I guess, it is probably just going to work and most probably nobody cared enough to actually do it. But lets stick to T146285

In T178538#3727988, @Krinkle wrote:

• Verify the hypothesis. Ensure MediaWiki works and tests pass under the proposed HHVM version and configuration.

Since HHVM 3.18 is what we're currently running in production and is what's used for CI jobs such as mediawiki-phpunit-hhvm-jessie and mediawiki-extensions-hhvm-jessie, I think there's a very good chance it does.