[08:56:53] <_joe_> searching a kind soul who would review https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEvents/+/508172/ so that it can be backported and SWATTed later this week [08:58:00] <_joe_> also https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/508177/, but I got a +1 there [09:44:20] _joe_: If I merged that now it'll roll out in the train in a couple of hours' time. Is that what you want? [09:45:00] (I already had it marked in my head as "C+2 as soon as the train is cut".) [09:45:10] <_joe_> uhm, probably not. I don't have time to followup right now [09:45:19] <_joe_> and I'm in the middle of perf reviews [09:45:26] Kk. [15:11:36] bpirkle: https://doc.wikimedia.org/cover/mediawiki-core/includes/filerepo/index.html and https://doc.wikimedia.org/cover/mediawiki-core/includes/filerepo/file/index.html [15:11:49] eeek... [15:12:04] yikes! [15:12:33] it could just be bad @covers in some cases [15:12:58] it's quite possibel that we have to explicitely resource testing work on this (unit or api driven) before we can even think about merging that patch :/ [15:13:05] Yes, it could be [15:13:20] I don't have high hopes, though [15:13:40] I mean, I don't think it's going to take it upto 50%+... But there's often some reasonable increase to be gained [15:15:11] I'll take a look and see what I can learn. [15:34:42] <_joe_> duesen: that looks like a piece of code I'd feel confident modifying :D [15:43:52] _joe_: we have a patch open that touches all these files... :D [15:47:24] <_joe_> cool! lemme know when it hits the wikis, I'll ask some vacation! [15:47:45] _joe_: you don't take vaction :P [16:15:51] I wish Gerrit had a way to change the "resolved" status of a comment without having to add a useless additional comment, as sometimes I forget to check the box, and more often some people somehow wind up with all the comments they make marked resolved or unresolved. [16:31:06] <_joe_> anomie: uh +1 [16:31:21] <_joe_> I use the "done" button [23:34:16] any MaxSem here? [23:34:38] Maaayybeee? [23:34:41] just looking at https://phabricator.wikimedia.org/T187147 , this concerns Krinkle also [23:35:14] I think Krinkle said to me recently that we need wmerrors for PHP 7, because the current solution in PHP doesn't have backtraces [23:35:26] backtraces for fatal errors was actually the number one reason for writing wmerrors [23:35:40] because it speeds up analysis of issues so much [23:36:14] but I was busy (as of a week or two ago) [23:36:33] now I see on the task that MaxSem actually ported wmerrors to PHP 7 and then one day later abandoned the change [23:37:21] on the basis that "Platform is not interested in this" [23:37:24] Because you told me it's not needed cause Platform is hiring a contractor for that [23:37:36] right [23:37:46] bpirkle said that on the 23rd [23:38:10] I think bpirkle was just saying that we don't have time for it but it's needed anyway, that's why it was a candidate for a contractor [23:38:23] I don't think any contractor was ever hired or if that was really seriously considered [23:38:33] and if you just wrote the code, we don't need a contractor, right? [23:38:43] we just need to unabandon the change and review it [23:38:46] I wrote some code [23:39:00] It's like 0% tested [23:40:30] I don't think it was complete either, but I don't remember [23:40:40] If MaxSem's code works, or can reasonably be made to work, then yes, we absolutely don't need a contractor. I said what I did because in a planning meeting at the time it was discussed that we had a contractor budget available, it seemed no one was available internally, and that this seemed like a self-contained project that might be appropriate to outsource. [23:41:12] FWIW, I never looked at the abandoned patch, so I have no opinion any direction on that code. [23:42:46] ok, so if I unabandon it and review it, and write up what I think still needs to be done, MaxSem, would you consider doing the things? [23:43:38] I've no idea how hard this can be [23:44:12] there's only two things that I thought needed to be done, and you did one of them [23:44:21] Funny thing how we have a PHP core dev, but have him write Java [23:44:23] 1. fix it so it compiles [23:44:45] 2. review the alarm stuff and figure out if we still need it in PHP 7.1, or if we can do something different [23:45:02] the possibility on 2. is that we may be able to remove some of the code [23:45:23] 7.1? [23:45:27] I don't think there is any chance that a large amount of extra development is needed [23:45:31] 7.1+ [23:45:55] 7.1 introduced a concept of interrupting the VM for signal handling [23:46:04] it may help us out here [23:47:20] so I would do the reviewing bit and decide if we can do something different [23:47:31] and if we can, I would tell you what that thing is [23:47:38] I'm very rusty in C and have no Linux C experience, so wouldn't be able to get into signals in my research time [23:47:43] item 1 you've done already [23:48:37] And yeah, I can only dedicate 10% of my time to this [23:49:29] ok, so I'll do my part of this, and you can look at it when I'm done writing it up and see what you think