[00:35:30] TimStarling: yeah, that is out of date. MediaWiki talks directly to logstash these days using syslog formatted UDP datagrams. That is handled by the monolog layer [01:13:36] I talked about this some more in #mediawiki_security, logstash is indeed losing about 3k packets per second [01:56:03] Krinkle: re: phpunit, did you also see https://doc.wikimedia.org/cover/mediawiki-core/includes/GlobalFunctions.php.html#1134 ? [04:33:19] legoktm: Hm.. strange, they are all also ignored. [04:34:17] the only recent change is that hashar moved the coverage job to quibble/docker [15:07:58] legoktm: hm.. sorry about the tree suggestion. I actually meant something else, it would've been more efficient than the POC but also wouldn't have worked :P [15:08:05] I was thinking about it needing only one isset() [15:08:25] But the problem is that would not work, given that if org or org.wikimedia exists, you need org.wikimedia.foo to return true [15:08:50] I was solving the opposite problem if org returning true if org.wikimedia.foo exists. [15:08:57] of* [15:53:20] tgr: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/450049 [15:53:41] tgr: with this follow-up, can RevisionStoreFactory go in? [15:54:46] thanks! [16:04:00] Is some available to review (and hopefully +2) https://gerrit.wikimedia.org/r/c/mediawiki/core/+/449732 ? This is a follow-up related to T165768 - I'd neglected to add a minor change to Maintenance.php to the original (and already merged) patch set. I also need to change Maintenance.php for an unrelated task. So in the interest of tidiness, I'd like to wrap up the one change to the file before pushing the other. [16:04:01] T165768: $wgShowSQLErrors doesn't seem to be working anymore - https://phabricator.wikimedia.org/T165768 [16:07:40] bpirkle: that looks trivial enough, i'll merge it. but for future reference, if you have a situation like this, Gerrit supports changesets that depend on other changesets. you just create the two (or more) commits on top of each other, and push them all for review at once. [16:08:28] Thank you MatmaRex , both for the merge and for the guidance! [17:59:05] tgr: i'm about to look into the diff patch agin. I'm having a hard time wrapping my head around the details again though, being away for two weeks didn't help [17:59:22] tgr: I'll probably just step through it locally. [17:59:32] can I help somehow? [17:59:32] are there any bits or aspects you particularly want me to look at? [18:00:07] ...i'll add notes when I get confused :) [18:00:10] the page language stuff is the one I was most unsure about [18:00:37] the current code uses content language where I think it should use page language [18:00:55] oh, i have one question already: the deprecated content-level methods of DifferenceEngine - what are they supposed to do now? operate on the main slot, right? [18:01:13] I kept it like that, since unlike DifferenceEngine SlotDiffRenderer does not have access to page metadata so it was convenient [18:01:37] not sure if that's a good idea or not [18:01:57] re language: in the case of wikidata, the output is in the *user* language... [18:02:30] user language is not a problem, SlotRoleRenderer gets the context [18:02:45] but it does not get anything specific to the diff [18:03:01] it could get a WikiPage [18:03:03] yeah, the content-level methods proxy to the main slot role handler [18:03:18] I don't see a problem with that (except for the fact that WikiPage should be replaced by PageRecord) [18:03:46] and the content-level properties expose main slot data, and if you try to change them it won't do anything useful [18:04:11] but then changing the public properties was already sketchy before the patch and no one in gerrit did it [18:05:20] you'd need two WikiPages, since the two sides of the diff are not required to be the same page (or the same language) [18:06:19] true [18:06:27] i'd just ignore that [18:06:53] odd edge case. you can't get there visa the ui, you'd need to manually edit the url [18:36:15] Krinkle: ahh. well it was a fun experiment, and I got to play with benchmarker :p [21:44:29] legoktm: how do we go about https://phabricator.wikimedia.org/T199761 ? [21:45:50] MaxSem: https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/zuul/parameter_functions.py#465 submit a patch? There's another open patch to add one more extension to gate, so I was going to review those later today or tomorrow once the CI fires were out [21:56:36] legoktm: this I know, but what about per-branch gating? [21:57:06] MaxSem: per branch doesn't really matter anymore, we no longer run the wmf- jobs on REL branches [21:57:31] ahhh [21:58:02] I was totally confused how those quibble jobs work [21:58:17] so I'll basically revert your revert of me :] [21:58:52] things have changed a lot in the past month, hashar was going to write a blog post + email about it soon :) [23:42:53] TimStarling, would you be able to poke at https://phabricator.wikimedia.org/T200827 ? Dumping the non-tidy output from the API and then loading it into remex didn't produce any warnings with the benchmarkTidyFast fn in test.php .. so, likely it is specific to the compat layer in MW [23:43:28] Done for the day for now .. but I can take a look tomorrow / Monday, if you cannot. [23:46:50] I'm looking