Wikimedia Platform Engineering/MediaWiki Core Team/Check-ins/20140505
who: Brad, Bryan, Faidon, Antoine, Tim, Chris, Dan, Chad, Rob, Greg, Timo, Ori
Monthly report
[edit]https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2014/April#Platform_Engineering
Bug escalation
[edit]- 58881 phpunit 4.0 distributed by phar which is unsupported by mw/core wrapper => can’t test!
Antoine: addshore did a few changes today (linked in bug report). Can use some reviews.
- Timo / Aude stepped in already :-)
Prioritization Process
[edit]See email: http://lists.wikimedia.org/pipermail/mediawiki-core/2014-April/000054.html
Silence == assent? +1 (bd808)
Job queue
[edit]- Meeting tomorrow
- General consensus on things like better monitoring
SecurePoll
[edit]- 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
[edit]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
[edit]- 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
[edit]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
[edit]- https://www.mediawiki.org/wiki/Wikimedia_Release_and_QA_Team/Quarterly_review,_April_2014
- 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
[edit]- 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.
- 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.
- 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.
- It shouldn’t unless they don’t know how to write code.
- Would this affect things like Firefox’s search bar?
Hiring
[edit]- YAY :)