[00:42:50] 3Wikimedia-General-or-Unknown, MediaWiki-Core-Team, MediaWiki-extensions-Renameuser: Local rename of Nonoh@ruwiki failed midway through - https://phabricator.wikimedia.org/T85041#937386 (10Legoktm) 3NEW [00:50:02] dammit... [00:50:11] I was told when claim changes claim ID changes too [00:50:18] but that doesn't seem to be the case [00:51:39] this messes up so many things... [00:53:37] SMalyshev, NOBODY KNOWS WIKIDATA [00:53:53] that's encouraging :) [00:54:33] 3SUL-Finalization, MediaWiki-Core-Team, MediaWiki-extensions-Renameuser: Renameuser has no debug logging - https://phabricator.wikimedia.org/T85042#937411 (10Legoktm) 3NEW [01:05:49] yup, old dump for Q24517: "P279":[{"id":"Q24517$7A855A08-5DD0-41A6-9A36-E3AC3DE24B11","mainsnak":{"snaktype":"value","property":"P279","datatype":"wikibase-item","datavalue":{"value":{"entity-type":"item","numeric-id":2095}  - new dump has different value, same claim ID [01:06:36] SMalyshev, have you spoken to the WMDE people about it? [01:06:46] because they develop wikidata, WMF just hosts it [01:06:59] Krenair: not yet, do you know anybody specific? [01:08:22] aude or hoo [01:08:33] (and #wikidata :)) [01:08:36] ok, I'll ping aude when he's around [01:08:38] SMalyshev, https://wikimedia.de/wiki/Mitarbeitende#Software-Entwicklung [01:09:17] aude is a she :) [01:11:30] legoktm: ok then :) [01:11:50] I wonder if there's some place where IRC nicks are listed along with people's real names [01:13:54] SMalyshev: https://www.mediawiki.org/wiki/Developers/Accounts and https://github.com/wikimedia/USERINFO [01:15:00] legoktm: aha, thanks! that helps a lot [01:16:59] and there's a list on officewiki, but that's only wmf staff [01:17:58] legoktm: yes, I found that one but no WMDE people there as it seems [01:19:59] AaronS: are you supporting updates with your orientDB work? [14:24:51] AaronS: In case you're around: How can I know whether my job queue group supports delayed jobs? [14:27:26] Ok, found it [21:30:04] 3MediaWiki-Core-Team, Librarization: Monolog logging configuration should support sampled logging - https://phabricator.wikimedia.org/T85067#937983 (10bd808) 3NEW a:3bd808 [22:54:22] 3MediaWiki-Core-Team: Deploy multi-lock PoolCounter change - https://phabricator.wikimedia.org/T85071#938038 (10aaron) 3NEW [23:08:10] bd808: do you think the sampling log handler should be upstreamed? [23:08:56] It might be worthwhile. I was thinking about doing that but wanted to unblock us first. :) [23:09:13] ok [23:11:20] I wish I had put all of those Monolog classes in a namespace [23:11:39] the faux namespace stuff I did with the classnames is goofy [23:13:56] namespaces in core? :PP [23:13:59] sofixit [23:16:10] I'm thinking about it. There would be some config patches that would have to synchronize with the merge and deploy since the class names are exposed in WMF's config. I guess I could do that safely in 2 parts with proxy classes first, then config change and finally killing the proxies [23:16:35] legoktm: and yeah we need to start putting namespaces in core IMO [23:17:05] 3MediaWiki-Core-Team, Wikimedia-General-or-Unknown: Report more information about php warnings - https://phabricator.wikimedia.org/T45086#938062 (10Krinkle) [23:18:58] legoktm: How many patches for librarization stuff do you have hanging out still? I'm about to declare bankruptcy on my review queue. :/ [23:19:30] I have the psr logging patch for bagostuff, which is blocked by monolog in prod [23:20:59] https://gerrit.wikimedia.org/r/#/c/180591/ php-composer-validate jobs for mw-config repo, https://gerrit.wikimedia.org/r/#/c/181004/ make-release script to fetch composer dependencies, https://gerrit.wikimedia.org/r/#/c/178264/ checkComposerLockUpToDate.php script, I need to respond to Tyler's feedback [23:21:05] hmmm.. we have psr3 in prod, just not with monolog backing. does it do something very monolog specific? [23:22:14] * bd808 stars those to not lose track [23:23:10] ooh. I started working on something like https://gerrit.wikimedia.org/r/#/c/178739/ as a composer plugin [23:25:41] legoktm: ah I remember the bagostuff thing now. Its the loss of the memcached-serious distinction right? [23:27:11] I like that patch though for sure. log levels! what a novel concept [23:27:21] yeah [23:29:15] I/we need to make some changes to the logging config for prod to go with that too. /me will file a ticket for the feature [23:30:06] basically to go along with the monolog config we should support setting a minimum log level in $wgDebugLogGroups [23:37:39] 3Librarization, MediaWiki-Core-Team: Support filtering log events by level in $wgDebugLogGroups - https://phabricator.wikimedia.org/T85073#938081 (10bd808) 3NEW [23:40:05] ori: I don't entirely understand your comment on my apache log parsing patch. "why 'message' and then 'msg_prefix'? make it 'message'" [23:40:25] msg_prefix is an optional match group [23:40:56] I couldn't find an easy way to merge an array of matches into a single item inside logstash [23:41:18] so that hack was what I could get to work reliably [23:42:47] and I should really put "reliably" in air quotes because I couldn't find a standard for how apache error logs are formatted and was playing trial-and-error with the messages I was seeing most often in the logs