Wikimedia Platform Engineering/MediaWiki Core Team/Check-ins/20140505

who: Brad, Bryan, Faidon, Antoine, Tim, Chris, Dan, Chad, Rob, Greg, Timo, Ori

Monthly report
https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2014/April#Platform_Engineering

Bug escalation
Antoine: addshore did a few changes today (linked in bug report). Can use some reviews.
 * 58881 phpunit 4.0 distributed by phar which is unsupported by mw/core wrapper => can’t test!
 * Timo / Aude stepped in already :-)

Prioritization Process
See email: http://lists.wikimedia.org/pipermail/mediawiki-core/2014-April/000054.html

Silence == assent? +1 (bd808)

Job queue

 * Meeting tomorrow
 * General consensus on things like better monitoring

SecurePoll

 * Poll creation UI prototype: http://mwcore-securepoll-test.wmflabs.org/wiki/Special:SecurePoll/create
 * Already some changes planned though, and the designers haven’t even looked at it yet (as far as Brad knows)

MediaWiki/CentralAuth token names
Varnish cache vary based on cookies matching a certain pattern. There was a prod issue last week because a new cookie was introduced that ended in “Token”, was served to anons and thus caused a lot of vary chain entries in Varnish. Faidon would like to look into changing the MW/CentralAuth token name to be more easily matched in Varnish without false positives.

Performance / HHVM

 * Brad reviewed Tim’s LuaSandbox patch and OK’d it; Tim merged
 * Needs to be committed into hhvm-dev tree.
 * FSS / wikidiff2 won’t build against latest master.
 * Ori tied up with EventLogging migration, Vagrant sprint and Zurich presentations.
 * Quick script made to compare parser output with cache (to be run in hhvm)
 * May 22nd (v3.1? v4.0? something like that)

RCStream
https://gerrit.wikimedia.org/r/#/c/131040/


 * Ops willing to provide operational support provided that is a comparable commitment from us to make this successful. This entails:
 * Fielding feature requests (and rejecting them, for the most part)
 * Supporting a migration from IRC to the feed
 * Misc. community-facing requirements that this setup entails
 * Ongoing maintenance of the Python code
 * Timo has stepped up and agreed to co-maintain this codebase.

Concretely, I think a commitment from our side entails the following:
 * Providing documentation sample client code
 * Make the argument for migrating from IRC and for the proposed infrastructure
 * Hold a workshop (at Wikimania, perhaps?) for bot maintainers
 * Bug triage

Why this matters: http://blog.hatnote.com/post/81329715894/a-beautifully-prepared-video-wall-installation Yeah, it’s hard to believe that wall is indirectly powered by IRC :-)

Antoine : make sure to get volunteers / bots author involved somehow :)

Deployment tooling / RelEng

 * https://www.mediawiki.org/wiki/Wikimedia_Release_and_QA_Team/Quarterly_review,_April_2014
 * Specifically https://www.mediawiki.org/wiki/Wikimedia_Release_and_QA_Team/Quarterly_review,_April_2014#Goals_2
 * Thursday deploy: Chad pushing the buttons, Dan as stand-in Greg (email to engineering@ forthcoming)
 * Hang on to your pants folks, gonna be a FUN day
 * Wikitech checklist for a Thursday deploy: https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment/Train_deploys
 * Give it a look and see what’s missing and/or what you think can be automated better
 * Based on checklist given to Bryan by Sam and added to by Bryan in March
 * Trebuchet deploying scap in Beta, patches for production in review
 * Yo dawg.

Search

 * Deployed new highlighter to Mediawiki.org (and test, test2, testwikidata)- found two bugs! Yay!
 * Fixing bugs and adding one missing feature. Deploying that tomorrow (probably) and giving it time to soak
 * Worked with matanya on irc on Friday - says Hebrew search is worse with cirrus than before.
 * Deploying plugin specifically for Hebrew uncovered bugs mentioned above so we’ll get to round two once that is in beta.
 * Swift plugin done. Deployed to beta
 * We need swift in beta for testing
 * Can deploy to prod once new boxes are fully weighted (soon) -- will roll out slowly so we don’t kill swift.
 * Having some trouble lately getting patches into Elasticsearch
 * Not 100% sure why but my primary contact just had a baby.
 * Slacker!
 * https://en.wikipedia.org/wiki/Human_reproduction ?
 * Want to file RFC about killing “Go” behavior from search. It’s a glorified “I’m Feeling Lucky” mode and makes me angry. Dan, can we talk?
 * Would this affect things like Firefox’s search bar?
 * It shouldn’t unless they don’t know how to write code.
 * Does hitting a URL like https://en.wikipedia.org/wiki/Special:Search?search=foobar&sourceid=mozilla-search count as not knowing how to write code? Brad would be sad if that required an extra click when “foobar” exists.
 * Firefox doesn’t have to hit that URL if they’re already pulling results from the opensearch API. Anyway, better discussion for an RFC.

Hiring

 * YAY :)