Wikimedia Platform Engineering/MediaWiki Core Team/Quarterly review, July 2014

This is an outline for a review of the MediaWiki Core team which will take place at WMF on July 16, 2014.
 * Notes for this review

Team
See Wikimedia MediaWiki Core Team page.

Changes since last review: (none)

Previous quarter
HHVM will be our flagship project. HHVM increases performance across the board on MediaWiki, and may eventually allow for the removal of the caching layer, thereby opening the doors for making the site more interactive and performant. In parallel with HHVM, the Search team will be focussing on getting CirrusSearch deployed on all Wikimedia wikis, and work will commence on the SUL finalisation.

The above work will continue alongside our team's ongoing responsibilities.

HHVM
We think that pushing HHVM toward full deployment is our best bet at achieving the greatest impact on end-users as a group. Historically, our strategy with respect to site performance was to rely heavily on a caching layer, based on the assumption that it is only a tiny minority of users that actually contribute content or personalize the interface, and that other users, representing the vast majority of visits to our projects, can be served by recycling generic views. This approach has allowed us to successfully scale to our current traffic levels, which is a significant feat. The cost of this approach has been twofold: it has concealed the user experience of logged-in editors, which is substantially degraded in comparison to anonymous users, and it has put a wall in front of our developers, frustrating most attempts to make the site more interactive or personalized for a bigger portion of our traffic. If we want to graduate features out of Beta and make them accessible to new users, we need to modernize our application server stack.

However, there are substantial risks to pushing this early. Debian packaging is still in a nascent state. The standard advice to developers is still to compile the very latest version from master because incompatibility bugs are still being fixed at a rapid pace. Rolling out HHVM would require extending our deployment system so that it builds a byte-code cache and synchronizes it to each application server. The mechanics of how we'll handle code changes, server restarts, etc. are still fuzzy. HHVM is not just a faster PHP: it's a totally new runtime that make many aspects of PHP that were previously set in stone highly configurable. It has completely new monitoring and profiling capabilities. It's a different beast, and it'll take us some time to become adequately familiar with it. So we can't promise that we only have one more quarter of work to do on this.

There are a couple of external dependencies that, if met, would accelerate our work:
 * A speedy Ubuntu 14.04 deployment
 * Assisting upstream with proper HHVM packaging

We have pretty good momentum right now. Both HHVM's upstream at Facebook and our own TechOps team have been very supportive of our work and are eager to see us deploy this. We want to keep going.

CirrusSearch Deployment
The nature of the work, namely for CirrusSearch to have feature parity with LuceneSearch, means that the cautious deployment of CirrusSearch is mainly due to hardware concerns. We hope to have CirrusSearch live everywhere by the end of the quarter.

Search page redesign
The goal of this project is to modernise the search results page and ensure we have a sensible user interface on top of which we can expose new features made possible by CirrusSearch, such as interwiki search.

As such, the main focus of the Search team this quarter is the deployment of CirrusSearch. Any spare cycles will be spent on the search page redesign project.

SUL finalisation
In the previous quarter, it was found that admin tools development was either blocked by SUL finalisation or would be made significantly easier in a post-finalisation world. However, the SUL finalisation would result in tools like local RenameUser being disabled, so there is engineering work to do before the finalisation can happen. This work has been scoped and a set of business requirements was developed.

Kunal Mehta (Legoktm) has agreed to do the necessary engineering work after he has finished his work on the Flow API. Chris Steipp will do general and security code reviews. Dan Garry will work on the product aspects of the finalisation, namely deciding the rules by which clashes are resolved, and also making sure that all the appropriate messages are properly translated and that every user who is affected by the finalisation is contacted in some form.

Scap
Work will continue on moving Scap fully to Python. Additionally, Bryan will help integrate HHVM functionality into Scap, such as bytecode cache distribution.

SecurePoll Redesign
The work has been scoped and mockups were produced by Brandon. Development continues.

Architecture/RFC Review
Tim's time should free up a little bit after LuaSandbox is ported over to HHVM, so he's planning on spending more time on leading the community on architectural improvements. One thing that the team will try as a secondary task (to HHVM) is making initial steps toward moving our site configuration out of directly-accessed globals (see Talk:Architecture Summit 2014/Configuration).

Previous Quarter People Allocations
Our people allocations for July through September of 2014:
 * Tim Starling: HHVM, Architecture/RFC Review, other review
 * Bryan Davis: scap, LogStash, HHVM
 * Nik Everett: Search
 * Chad Horohoe: Search, HHVM
 * Brad Jorsch: SecurePoll cleanup, API Maintenance, Scribunto Maintenance
 * Ori Livneh: Performance Infrastructure, HHVM
 * Aaron Schulz: HHVM
 * Chris Steipp: Security reviews, SUL finalisation
 * Antoine Musso: CI for HHVM, scap pythonization
 * Sam Reed: Deployments
 * Dan Garry: Search, SecurePoll, SUL finalisation
 * Greg Grossmeier: RelEng+QA, Deployment Tooling

Upcoming quarter
From the annual Wikimedia Engineering goals doc

HHVM

 * Full HHVM deployment.

Quant target: By September 2014, we aim to halve median backend response time for uncached operations, including page preview and save.

Performance

 * Establish key performance indicators for end-to-end response time and server performance

Search
Feature complete, achieving parity with legacy system (lsearchd) in all reasonable respects

API

 * API discoverability improvements

Upcoming Quarter People Allocations
Our people allocations for July through September of 2014:
 * Aaron Schulz: HHVM, general performance
 * Ori Livneh: HHVM, performance metrics
 * Tim Starling: HHVM, Architecture/RFC Review, other review
 * Chad Horohoe: Search
 * Nik Everett: Search
 * Bryan Davis: SUL finalisation (time permitting: Deployment Tooling, LogStash, HHVM)
 * Chris Steipp: SUL finalisation, Security reviews
 * Dan Garry: SUL finalisation, Search, SecurePoll
 * Brad Jorsch: API discoverability improvements, API Maintenance, Scribunto Maintenance
 * Antoine Musso: see Wikimedia Release and QA Team
 * Greg Grossmeier: see Wikimedia Release and QA Team
 * Sam Reed: see Wikimedia Release and QA Team

Ongoing responsibilities

 * Deployments
 * Core deployments
 * External team deployments (e.g. Wikidata)
 * MediaWiki operations (performance, debugging, ops team support)
 * Code review
 * API maintenance and code review (Brad: 30%)
 * (fill me in)
 * Security issue response
 * Test infrastructure (Beta cluster and continuous integration)
 * Git/Gerrit improvement
 * Shell bugs