Wikimedia Platform Engineering/MediaWiki Core Team/checkin-20131007

Who Bryan, Nik, Brad, Greg, Aaron, Ori, Chad, Chris S, RobLa, Antoine, Tim

Yay Ori Antoine: for those that don’t know Ori yet: he is very excited to work with such smart people. Bryan: He can tell you where to get a toasted sandwich at any hour of the day or night. (Except on Saturday)

Password Hash Disclosure Chris is mainly working on proper password reset.

SUL Are we done here?
 * Yeah pretty much

OAuth
 * 1 patch to review, 1 patch from aaron in progress - end of buglist
 * 1 bug (https://bugzilla.wikimedia.org/show_bug.cgi?id=54716) assigned to Dan, waiting on decision about link vs button

OpenID
 * Wikinaut is working on bugs, no eta

Search
 * Now have load balancing \o/
 * Needs improved health checking
 * cawiki is primary
 * Fix today for prefix: issue (cawiki complaining)
 * enwikisource to be primary this week
 * Search hardware request: RT 5883

Other
 * Bug 53687 -- Tim has been working on this
 * Gerrit 87281 - More HHVM fun from Chad
 * Antoine: do we have a debian package / puppet manifest ? Might want to run tests under HHVM :D
 * libevent refactor in progress, can look at packaging it once done.
 * Vagrant feature request for HHVM role

Performance
 * Erik requested data about VE performance; especially the time it takes to activate the editor and the time it takes to save edits.
 * Initial focus: time it takes VisualEditor to fetch an editable DOM upon being enabled.

Jul 25 08:17:33    The slowest steps AFAIK are building the CE tree (which includes building the display DOM), doing initialization on that CE DOM (which has a lot of room for improvement), building the DM tree, and doing the DOM->linmod conversion, in descending order ... Jul 25 08:20:12    is there a reason you don't just have the server cache a CE tree and have the client request it as JSON or something? ... Jul 25 08:21:00    TimStarling: That would probably help a fair bit, we've also considered refactoring the CE stuff so it doesn't build a DOM from scratch but uses the Parsoid DOM as a base … Jul 25 08:31:35    TimStarling: Thanks for the "what if you moved this server-side" suggestion, somehow none of us had thought of that (we're all frontend devs, I wonder why ;) ) and it's a very helpful and interesting suggestion


 * Added 'X-Parsoid-Performance' header to report performance internals; have VisualEditor API module pass it through; will log this data + additional client-side latency measurements via EventLogging.
 * Graphite is moving from professor (tampa) to tungsten (eqiad). Needs udpprofile, which has not been migrated from SVN to git, and which is not packaged for Precise. RT 5882.
 * Alternately, have MediaWiki emit profiling metrics in StatsD format (Change Iaf00811d3) (Is there anything else that depends on the data format? What is powering noc.wikimedia.org/cgi-bin/report.py ?)
 * Personal goal: cache RL modules in localStorage; https://gerrit.wikimedia.org/r/#/c/86867/
 * Navigation timing & client-side payload info on Ganglia; Ori wants to expand this to logged in users. What does it all mean? Working that out on Wikitech. Help appreciated.
 * Ori needs a lot of help / guidance :)
 * Get data in the console about RL modules used to render page: https://en.wikipedia.org/wiki/User:Ori.livneh/common.js (need to put this in core)

RFC/Architecture

Quarterly review