[14:21:31] Ha, I see Adam copied my use of ∞ for "First code review SLA" on [[mw:User:ABaso (WMF)/Extension Responsibility]] [15:11:11] * anomie wonders if ApiQuerySiteinfo is really going to wind up with 25 constructor args if the DI thing reaches its end state. [17:51:48] anomie: That sounds maintainable [17:53:31] https://phabricator.wikimedia.org/T117475 [17:53:42] Reedy: I made a list at https://gerrit.wikimedia.org/r/#/c/250151/3/includes/api/ApiQuery.php line 121. [17:53:49] Funny how that's nearly every extension Jeroen has touched ;) [17:59:18] anomie: although I could poke one user and probably cut that in half <-- who's the user? [18:00:43] legoktm: Cyberpower678, operator of Cyberbot I [18:01:13] heh, I guessed right :P [18:27:20] MatmaRex, James_F|Away: So the Language people want you to import cldrjs into oojs-ui so we can have a datetime picker. [18:29:30] wait, why cldrjs? [18:29:41] Month and weekday names. [19:02:15] csteipp: Meeting? [19:03:08] anomie: Google is saying it can't connect... [21:04:01] bd808: Is there a task for stacktraces in logs? Also, what is the current status? Do we have them nowhere? Or we have them in fatals but not in notices/warnings yet? [21:07:42] ori: So we've disabled xhprof to statsd/graphite in prod. And we have xenon. What use case do we have left from the old days (or new desire) that we can't satisfy with xenon? [21:08:09] custom markers? [21:09:29] and potentially more accurate time spent, but it seems to me graphite is not a suitable storage for that as it allows no relational querying. The old cgi thing we had was quite nice. Not sure what kind of storage would be suitable to re-create that. [21:10:00] custom markers we may be able to do with statsd/measure instead (with help of Timing maybe) [21:33:20] Krinkle: we have stacktraces for fatals from my work on T107440 but not notice/errors. T45086 was the bug for notice/errors. Nobody has work on that part for quite a while. Having stacktraces for everything would be quite an increase in log data that needs to be stored. [22:26:14] bd808: Right [22:26:20] bd808: But we should also fix our notices/errors :P [22:26:55] agreed [22:27:33] Goes back to the idea of having a way to uniquely identify them, and have them autodump into phab [22:27:33] :D [22:27:57] tgr hasn't given up on that yet. [22:28:08] The stack for a particular code hit should be deterministic [22:28:12] The de-duplication part? [22:28:17] yeah [22:28:20] sweet :) [22:28:21] the rest of the entry object will not be (due to refer and wiki etc.) [22:28:25] with Sentry [22:28:31] but yeah, in theory we can dedupe [22:28:45] It doesn't have to be perfect [22:28:51] we can group in a kibana query by message though [22:28:55] Which is good enough [22:29:00] it's just redundant storage [22:29:06] I think all Sentry is stuck on at the moment is ldap auth integration [22:29:11] being able to see if it's more common on one wiki than another is always useful anyway [22:29:11] As long as it doesn't create more than a few for the same logspam entry etc [22:29:34] but he's supposed to only work on that in his "spare" time. /me takes off manager hat [22:29:58] It still makes me laugh how quickly that log file filled up when Krinkle and I started logging notices and such [22:32:33] It'd certainly gain a lot of GCI type tasks if they ended up in phab [22:32:34] * Reedy grins [22:37:14] I wonder how bad the log would be now [22:37:41] turn it on for a few minutes and see? :P [22:38:11] Yeah, I'm tempted [22:39:13] Would have to work out where that would be now... [22:40:06] InitialiseSettings.php wmgMonologChannels [22:40:45] ah, there it is [22:40:45] :D [22:40:55] Stage on tin and sync-common from mw1017 [22:41:11] then browser with ChromeWikimediaDebug to en.wiki and a few other wikis to see what the default data flow gives us [22:41:31] Passing X-Debug will make any wiki request go to mw1017, not just testwiki [22:41:33] I was wondering about doing something like that [22:41:37] though even testwiki will give us a good indication [22:41:42] tgr filed a task asking for me to figure out how to log all the things on mw1017. I need to look into that [22:42:03] That'd be not a bad way of doing it either [22:42:11] Ah, to make it sticky (not a deploy test) we'd probbaly have to conditional on hostname. [22:42:36] That seems quite reasonable actually since a lot of the static noise we'll start with is happening even on plain requests to testwiki. A good starting point. [22:42:43] yeah. we were thinking about an extra monolog handler for all the channels [22:44:02] it's "on my list" [22:44:22] https://phabricator.wikimedia.org/T117020 [22:45:01] kind of related to https://phabricator.wikimedia.org/T117019 as well [22:47:00] still, might be worth enabling the 'error' error log for a few minutes and start filing tasks based on it [22:47:23] no objectsion from me [22:47:28] *objections [22:47:55] just don't fill up the disk on fluorine ;) [22:48:06] hence a few minutes :P [22:48:24] Not sending to logstash would probably be good too [22:48:27] what would the value be to just have it go to fluorine? [22:48:28] yeah [22:48:40] I've had enough fun freeing disk there already this week [22:49:06] umm... let me look to remember [22:49:33] I'm guessing array( 'logstash' => false ) woul be part of it [22:49:34] :D [22:49:49] array( 'udp2log' => 'debug', 'logstash' => false, ) [22:50:24] I think just "array( 'logstash' => false )," works too [22:50:28] see api.log [22:50:34] 'bug46577' => 'debug', // Education Program debugging [22:50:43] That bug is closed... I suspect that entry can go [22:50:52] kill the old crappy logs! [22:50:55] ja [22:51:02] I wonder how many other task specific ones are still open [22:52:01] Tehre are quite a few named T* [22:52:14] first one I tried, T89258 is closed [22:52:25] T102199 is closed too [22:52:57] T87645 is open [22:53:11] So is T76305 [22:53:41] Disabling 3 is a net win [22:55:04] https://gerrit.wikimedia.org/r/250850 [22:57:16] I'll enable the error log for 5 minutes or so tomorrow when I'm around to watch it [22:59:11] I get to have some sort of meeting about phone systems tomororw [22:59:14] Won't that be fun [23:00:00] so fun. TL;DR they all suck and cost way too much [23:00:34] Scarily, we can replace the whole system (including handsets) for less than it cost to just have the dect system put in [23:01:22] the VOIP phones at my wife's office only work if the receptionist is logged into her workstation :/ [23:01:25] Going to get my dads office recabled aswell, as part of the upgrades, so that'll be nice [23:01:36] lol [23:01:48] I have no idea how they messed that up [23:02:08] They put some management app in the start up folder of her windows computer? [23:02:11] Phone system is a major SPOF... Installed 13 years ago, out of maintenance contract for a couple of years... No parts etc [23:02:49] this is voip the industry over [23:14:02] legoktm: https://github.com/wikimedia/composer-merge-plugin/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.3.0 plus one more I'm waiting on the self version patch for. We can get 1.3.0 shipped this week I think if you can find time for reviews [23:14:27] they we can start to figure out how to use differential instead [23:14:38] which one should I review first? [23:14:48] https://github.com/wikimedia/composer-merge-plugin/pull/89