[00:04:47] Krinkle: server side - parse time, to be precise
[01:09:38] MaxSem: Hm. well, we have the save timing metric at https://grafana.wikimedia.org/dashboard/db/save-timing?panelId=22&fullscreen&orgId=1 (frontend save timing, for enwiki and a few other group2 wikis)
[01:10:06] and at the bottom of https://grafana.wikimedia.org/dashboard/db/backend-save-timing-breakdown?refresh=5m&orgId=1 we have backend save timing (whicih is mostly parsing) by page type ("content" is main namespace)
[01:13:48] there is also the slow-parse log in Logstash, which is about the non-save use case, e.g. when viewing pages after purge or cache expire.
[01:14:26] Thanks, Krinkle - we'll keep an eye on these
[01:17:25] MaxSem: yw. By the way, the reason I recommend group2 is because group1 has wikidata which is most of the samples there and behaves differently to avoid skew
[01:17:53] Yeah, a completely different beast
[01:18:45] Back in maps times, Yurik just insisted that we have all the metrics per wiki
[01:30:29] Meh, it depends. The application can certainly do that. But the problem there is that it makes metrics grow unwieldly, with most of them unstable/unusable due to too low sampling, remembering that this is mostly recorded per-minute.
[01:30:47] Variables in metric names is usually a problem.
[01:31:12] But even within a wiki, e.g. Flow pages are very different from articles, and even talk pages with wikitext behave differently from articles from perf perspective.
[01:31:25] Maybe for parsing/saving, we can fragment by content model.
[01:31:41] That would replace the one we have for page type, so that wikidata items and articles aren't together as "main namespace"
[02:57:35] https://tracker.debian.org/news/1001729/accepted-php-excimer-010git201810255675679-1-source-amd64-into-unstable-unstable/
[03:15:20] better make sure it works now
[03:45:34] :)
[03:45:47] TimStarling: is cscott's hunch on https://phabricator.wikimedia.org/T199332#4416153 correct (or likely correct)?
[03:59:12] I don't think so, I wrote a comment
[06:50:52] legoktm: ahah you're doing my job for me <3
[06:50:57] (re: excimer)
[14:46:47] addshore: I see you moved https://phabricator.wikimedia.org/T87781 to stalled earlier this year; do you know of any plans to revive this & related tasks, like https://phabricator.wikimedia.org/T89432?
[18:10:56] hi, does anyone know how i can fix "TypeError from line 144 of /srv/mediawiki/w/extensions/CentralAuth/includes/CentralAuthUser.php: Argument 1 passed to CentralAuthUser::getMasterInstance() must be an instance of User, null given, called in /srv/mediawiki/w/extensions/Flow/includes/TalkpageManager.php on line 254"?
[18:21:07] anomie could you review / merge https://gerrit.wikimedia.org/r/472509 pelase? :)
[18:21:16] (im thinking my error will be fixed by that but not sure)
[18:26:14] nvm still fails with that change
[19:32:20] shouldn't the fix be on Flow?
[19:32:36] looks like it is passing a null where it should pass a user
[21:09:40] Platonides yeh
[21:09:43] i have a fix
[21:10:06] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/472516
[21:12:51] paladox: you should file a proper bug with a full stacktrace
[21:12:56] ok
[21:12:57] instead of linking to a pastebin
[21:15:11] done
[21:15:16] https://phabricator.wikimedia.org/T209113
[21:15:18] legoktm ^^
[21:15:34] cool
[21:44:38] paladox: commentted there
[21:45:51] Platonides thanks, done!
[21:51:58] LGTM
[21:52:05] :)
[21:52:09] thanks! :)