[00:04:47] <MaxSem>	 Krinkle: server side - parse time, to be precise
[01:09:38] <Krinkle>	 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] <Krinkle>	 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] <Krinkle>	 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] <MaxSem>	 Thanks, Krinkle - we'll keep an eye on these
[01:17:25] <Krinkle>	 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] <MaxSem>	 Yeah, a completely different beast
[01:18:45] <MaxSem>	 Back in maps times, Yurik just insisted that we have all the metrics per wiki
[01:30:29] <Krinkle>	 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] <Krinkle>	 Variables in metric names is usually a problem.
[01:31:12] <Krinkle>	 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] <Krinkle>	 Maybe for parsing/saving, we can fragment by content model.
[01:31:41] <Krinkle>	 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] <legoktm>	 https://tracker.debian.org/news/1001729/accepted-php-excimer-010git201810255675679-1-source-amd64-into-unstable-unstable/
[03:15:20] <TimStarling>	 better make sure it works now
[03:45:34] <legoktm>	 :)
[03:45:47] <legoktm>	 TimStarling: is cscott's hunch on https://phabricator.wikimedia.org/T199332#4416153 correct (or likely correct)?
[03:59:12] <TimStarling>	 I don't think so, I wrote a comment
[06:50:52] <_joe_>	 legoktm: ahah you're doing my job for me <3
[06:50:57] <_joe_>	 (re: excimer)
[14:46:47] <kostajh>	 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] <paladox>	 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] <paladox>	 anomie could you review / merge https://gerrit.wikimedia.org/r/472509 pelase? :)
[18:21:16] <paladox>	 (im thinking my error will be fixed by that but not sure)
[18:26:14] <paladox>	 nvm still fails with that change
[19:32:20] <Platonides>	 shouldn't the fix be on Flow?
[19:32:36] <Platonides>	 looks like it is passing a null where it should pass a user
[21:09:40] <paladox>	 Platonides yeh
[21:09:43] <paladox>	 i have a fix
[21:10:06] <paladox>	 https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/472516
[21:12:51] <legoktm>	 paladox: you should file a proper bug with a full stacktrace
[21:12:56] <paladox>	 ok
[21:12:57] <legoktm>	 instead of linking to a pastebin
[21:15:11] <paladox>	 done
[21:15:16] <paladox>	 https://phabricator.wikimedia.org/T209113
[21:15:18] <paladox>	 legoktm ^^
[21:15:34] <legoktm>	 cool
[21:44:38] <Platonides>	 paladox: commentted there
[21:45:51] <paladox>	 Platonides thanks, done!
[21:51:58] <Platonides>	 LGTM
[21:52:05] <Platonides>	 :)
[21:52:09] <paladox>	 thanks! :)