Hi everyone,
I have a working session with Dan tomorrow to do major work on the wiki page here: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revie...
Given the relative lack of controversy around just going with HHVM, the clear end-user benefit, and the lack of a well-articulated and deeply-championed alternative, I think there's less urgency in getting a consultative mail out to wikitech-l in advance of our quarterly review. Nevertheless, I think it sets good precedent, so I'd like to do it anyway. I'd like to have a solid articulation of all of the work that we're doing in addition to the work we've considered and decided not to do this time around, so that people are informed about what we're not doing in addition to knowing what we are, and can make a last minute case for something else.
I don't have a draft of said email started, but it's basically going to be the highlights from the wiki page above. Dan and I will be editing between 11am and 12pm PDT tomorrow, so that's the main time to avoid doing a lot of work there. Any time before or after that is fair game, so please take a look at it, and if there's areas that you feel you can fill stuff in prior to our meeting, or elaborate/correct after our meeting, please do.
Thanks Rob
On Wed, Apr 9, 2014 at 10:43 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
I have a working session with Dan tomorrow to do major work on the wiki page here:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revie...
Given the relative lack of controversy around just going with HHVM, the clear end-user benefit, and the lack of a well-articulated and deeply-championed alternative, I think there's less urgency in getting a consultative mail out to wikitech-l in advance of our quarterly review. Nevertheless, I think it sets good precedent, so I'd like to do it anyway. I'd like to have a solid articulation of all of the work that we're doing in addition to the work we've considered and decided not to do this time around, so that people are informed about what we're not doing in addition to knowing what we are, and can make a last minute case for something else.
I don't have a draft of said email started, but it's basically going to be the highlights from the wiki page above. Dan and I will be editing between 11am and 12pm PDT tomorrow, so that's the main time to avoid doing a lot of work there. Any time before or after that is fair game, so please take a look at it, and if there's areas that you feel you can fill stuff in prior to our meeting, or elaborate/correct after our meeting, please do.
Thanks Rob
Status: Getting HHVM serving up beta (done by review?)
Yes. :) You can invite folks to check out < http://en.wikipedia.beta-hhvm.wmflabs.org/%3E, which is (finally) ready for public consumption.
On Thu, Apr 10, 2014 at 2:52 AM, Ori Livneh ori@wikimedia.org wrote:
On Wed, Apr 9, 2014 at 10:43 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
I have a working session with Dan tomorrow to do major work on the wiki page here:
https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revie...
Given the relative lack of controversy around just going with HHVM, the clear end-user benefit, and the lack of a well-articulated and deeply-championed alternative, I think there's less urgency in getting a consultative mail out to wikitech-l in advance of our quarterly review. Nevertheless, I think it sets good precedent, so I'd like to do it anyway. I'd like to have a solid articulation of all of the work that we're doing in addition to the work we've considered and decided not to do this time around, so that people are informed about what we're not doing in addition to knowing what we are, and can make a last minute case for something else.
I don't have a draft of said email started, but it's basically going to be the highlights from the wiki page above. Dan and I will be editing between 11am and 12pm PDT tomorrow, so that's the main time to avoid doing a lot of work there. Any time before or after that is fair game, so please take a look at it, and if there's areas that you feel you can fill stuff in prior to our meeting, or elaborate/correct after our meeting, please do.
Thanks Rob
Status: Getting HHVM serving up beta (done by review?)
Yes. :) You can invite folks to check out < http://en.wikipedia.beta-hhvm.wmflabs.org/%3E, which is (finally) ready for public consumption.
I will also note that Tim has added a '--no-fun' command-line argument to HHVM's test runner: < https://github.com/facebook/hhvm/commit/f9af3076f13763773bec39788b7ce86a5416...
Le 10/04/2014 11:52, Ori Livneh a écrit :
Yes. :) You can invite folks to check out http://en.wikipedia.beta-hhvm.wmflabs.org/, which is (finally) ready for public consumption.
I must praise Bryan and Ori there.
Ori managed to sneak the hhvm deployment on beta cluster while I was migrating to eqiad and Bryan added a puppetmaster and started scap there.
Surprisingly, we did not wipe out the beta cluster and it remained mostly functional apart for some little annoying issues.
Over the course of a month we made huge progresses and have beta in a much better shape \O/
Le 10/04/2014 07:43, Rob Lanphier a écrit :
I have a working session with Dan tomorrow to do major work on the wiki page here: https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Quarterly_revie...
Mail is all about hhvm
== testing ==
For hhvm we have a lot of cross dependencies. I would love us to come with an integration test plan to make sure that a new HHVM version does not break the ported PHP extensions and that the PHP extensions are compatible with the tip of hhvm as well as the deployed version.
Zuul has supports for cross repositories dependencies. I am working on a patch to make it easy to fetch the proper versions on each repository which would let us write nice integration jobs.
The idea would be roughly:
a change is made to hhvm@<branch> - trigger job to build hhvm@<branch> + proposed patch - trigger jobs for each of the extension@<branch> against the patched hhvm
a change is made to extension@<branch> - trigger jobs to build that patched extension against hhvm@<branch>
We could also have job to make sure a change made to an extension@master remains compatible with the hhvm@production.
== hhvm tweaks to execute tests ==
Still on hhvm front, there is a lot of various configuration settings. We run the MediaWiki core PHPUnit tests with:
Eval.Jit=1 Debug.CoreDumpReportDirectory="$LOG_DIR" Repo.Central.Path="$WORKSPACE/hhvm.hhbc.sqlite"
There is probably a lot more settings we should set there or on the future application servers.
Ie:
hhvm -vEval.Jit=1 \ -vDebug.CoreDumpReportDirectory="$LOG_DIR" \ -vRepo.Central.Path="$WORKSPACE/hhvm.hhbc.sqlite" \ --php phpunit.php \ --with-phpunitdir "$PHPUNIT_DIR" \ --conf "$MW_INSTALL_PATH/LocalSettings.php" \ --log-junit $JUNIT_DEST
https://github.com/wikimedia/integration-jenkins/blob/master/bin/mw-run-phpu...
== target architecture ==
We would need to brainstorm about the targeted architecture and how to migrate to it. I dont think we can run PHP/Apaches and hhvm on the same boxes. Potentially we could have a whole new cluster of hhvm application servers and have Varnish routes requests to hhvm based on a switch (maybe a betafeatures cookie?).
mediawiki-core@lists.wikimedia.org