Scrum of scrums/2016-02-24
- Blocking: (nobody we know)
- Blocked: (on nothing)
- Upgraded to CDH 5.5, comes with lots of improvements for those using the Hadoop cluster: http://www.cloudera.com/documentation/enterprise/latest/topics/cdh_rn_new_in_550.html
- Internally released data that estimates the number of Unique Devices hitting each of our domains, using the Last Access cookie. This is a major release, and it's available in the wmf database in hive, in the last_access_uniques_daily table.
- Fixed handling of uri-encoded page titles in the pageview API
- Update train email as to why stalled
- AQS deployed via Scap3, (hooray \o/ +1) ready for new services w/new version
- Phabricator updates happened, puppet work continues
- Train (still) not running wmf.14 on testwiki and that's all
- nothing we know of
- blocked on ops for ORES in production
- also blocks deployment of ORES extension to fawiki and wikidata
- halfak would like to engage with ops - could someone contact him?
- blocked on ops for ORES in production
- Working through lots of security bugs
- PageViewInfo review in progress
- none afaik
- Would like Ops input for https://phabricator.wikimedia.org/T126730 (caching model for WDQS)
- Would like Sec review on SVG sanitizer JS lib
- Would like Sec review on Schema validator php lib
- Preparing to switch completion suggester into production (March)
- A number of new interesting graphs at http://discovery.wmflabs.org/ e.g. http://discovery.wmflabs.org/metrics/#failure_langproj, http://discovery.wmflabs.org/portal/#browser_breakdown
- Not much new, mostly bugfixes, tweaks and maintenance
- Pageview API graphs getting popular
- External Store - In progress. Will soon enable External Store on Beta Cluster as a pre-requisite for this. If you want to look/give feedback on the Beta change, see https://phabricator.wikimedia.org/T95871
- Enabled Echo cross-wiki notifications feature on initial wave of wikis. Good feedback so far.
- Working on some issues with Flow board moves.
- Also, not a Collaboration team thing, but we've asked for feedback on some Code of Conduct proposed changes: https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_changes
- Templatedata based serialization being deployed today (https://phabricator.wikimedia.org/T111674 and https://phabricator.wikimedia.org/T104599 )
- Kunal and Ori have been investigating https://phabricator.wikimedia.org/T124356 ... Ori might have made some headway there.
- Filed https://phabricator.wikimedia.org/T127757 to fix getText() semantics to prevent this kind of sneaky bugs in the future.
- Heads up for release engineering: https://phabricator.wikimedia.org/T111259 bit us once more recently.
- None known.
- Waiting on Design Research availability for user testing of Single Edit Tab integration
- Single Edit Tab went to Hungarian Wikipedia yesterday; now waiting on user feedback.
- Some improvements to OOUI; note the breaking change for wmf.15+ (no known issues in gerrit master code).
- Last week we said we'd update on assessing the performance impact of OOUI on all read pages; this is not firm yet, but appears to be a trivial additional cost.
- No blockers/blocking
- Investigating anomalies
- Improving CiviCRM reporting
- Testing backup processor improvements
- Further Latin America processor work
- Nothing to report.
- We've been mostly chasing performance issues that people found that touch stuff SessionManager also touched.
- In the not too distant future, load.php is going to start enforcing the fact that it's supposed to not depend on the session or the request data.
- See https://phabricator.wikimedia.org/T127233 and subtasks.
- Check your ResourceLoaderModule subclasses and your 'ResourceLoaderGetConfigVars' hook functions to make sure you're not using $wgUser or $wgLang (or their equivalents via RequestContext). You'll generally want to use the user and language from the ResourceLoaderContext or use the 'MakeGlobalVariablesScript' hook instead. Remember that Message objects will use $wgLang by default.
- Check your parser hooks to make sure you're using $parserOptions->getUser() or $parser->getTargetLanguage() instead of $wgUser or $wgLang (or their equivalents via RequestContext), respectively. Otherwise you're liable to blow things up if your hook gets used in a message somewhere.
- Timo says he'll send an announcement of some sort once details are settled.