[17:05:04] * anomie sees https://gerrit.wikimedia.org/r/402076 and wonders whether replacing 9 characters with 53 to do the exact same thing is really an improvement (or if the deprecation should be undone). [17:09:50] I'm wondering similar for https://gerrit.wikimedia.org/r/#/c/395148/ [17:18:53] I suppose the idea behind the deprecation is that everything somehow shouldn't be calling MediaWikiServices::getInstance() all over the place. Which implies that adding said calls all over the place isn't the right fix. [17:19:46] dependency injection done wrong [17:20:27] "MediaWikiServices" is a horrible class name too, but I guess pre namespacing its mostly safe [17:20:52] * bd808 wanders back to python utility scripts [17:34:31] We had this discussion before when there was talk of deprecating wfGetFile() [17:35:05] I guess the question is how widely used something is to see if it's worth the shortcut or not [17:35:23] (in wfFindFile()'s case, it's called enough that the character savings is worth the layer of indirection) [17:35:30] (not speaking for wfGetLB()) [17:37:30] MediaWikiServices / RequestContext::getMain() --- allowing developers to feel like they're getting rid of globals without getting rid of a global state ;-) [17:41:43] I spent *months* thinking about how to do a proper DI/IoC container for MediaWiki. My end answer was that it is mostly not possible due to wikitext/parser. As soon as you enter the parser you have to be able to get *anything* from *anywhere* [17:42:26] so a lot of things can be done to clean up outside of the parser for sure, but in the end we can't have true IoC [17:43:12] I should dust off killing $wgTitle :p [17:43:28] Meh, 99 problems [17:47:27] having DI for things other than the parser is a decent goal [17:48:15] for 99% of devs the parser is too scary to touch anyway so it's not the low-hanging fruit for making code more developer-friendly / easier to change [17:48:44] (although whether DI makes code more developer-friendly in PHP is somewhat debatable) [17:49:36] but yeah, those patches do voodoo dependency injection [20:03:18] DanielK_WMDE_: Somewhere in the huge pile of MCR tasks, is there one for "Configure views for toolforge replicas"? It's not T174047 (making legacy views for BC), I'm asking about a task for making views for slots, content, content_models, and slot_roles themselves. [20:03:19] T174047: Provide backwards compatibility views for toolforge replica [MCR] - https://phabricator.wikimedia.org/T174047 [21:15:21] Krinkle: "Testing an e-mail to our old list. This should fail." [21:15:28] :-) [21:16:06] is there a new different list? [21:17:19] legoktm: moved from lists.* to google group for internal mail [21:17:36] ah, so it's not a public list anymore? [21:18:19] legoktm: it wasn't a public list. performance@ still continues to exist, though. [21:18:26] although we usually use wikitech-l instead. [21:18:45] performance-team@lists. was a private list, only public for incoming mail. The same applies to the @wikimedia.org list. [21:19:01] you sent the email to performance@ [21:19:11] Yes, and I replied already to clarify my mistake. [21:19:14] I was testing the wrong list. [21:19:19] ah [21:19:24] I didn't recheck my email :p