[07:24:14] tgr: Hi, sorry for poking here. Concerning https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Flow/+/505782, does that mean applying this approach to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/505781? [07:24:36] Or maybe I should spend sometime seeing if people still use external diff these days? [07:24:55] Taking into consideration that core says we can use Diff/UnifiedDiffFormatter [07:25:01] not sure if there's a way to check that [07:25:22] Okay, so Diff/UnifiedDiffFormatter is the way to go then? [07:25:32] probably [07:26:01] Out of curiosity, your approach seems to be another way out but I've not fully understood it yet tgr [07:26:02] TextSlotDiffRenderer::getTextDiffInternal is fast but will give you a HTML diff and it will take some hackyness to turn it into a text diff [07:26:25] Oh, I was just about to ask ;) [07:26:50] I now see why you mentioned the comparison part and carefulness :) [07:27:09] In that case, I can just replicate what I did in the patch in Flow, thanks :) [09:32:19] tgr|away: Yeah, the rebase hell is a real pain :) but one can easily forget some of what has been removed which will be difficult to blame. [17:08:39] xSavitar: I would just keep a list in a file [17:09:09] or a separate patch that's not rebased to be mergeable, if you want to be more transparent about it [17:09:34] you can add stuff there as you go and then merge it all at the same time [17:09:38] much less effort [17:51:57] tgr: Thanks a lot! [17:52:11] Can you share with me an example patch for this approach so I see how you do it? [18:00:53] I don't have one [18:01:51] just make a patch for adding a line to the release notes, and update it when a deprecated method removal patch gets merged [18:02:09] Okay [18:02:12] and maybe refer to it in those patches [18:02:37] Yep, referring to the change ids of the patches in question will be good. [18:05:07] tgr, hey, I was wondering what the status of deployment-sentry01 was [18:07:52] Krenair: unused for a long time [18:08:05] I've seen the alerts, haven't had time to look at them yet [18:08:29] does it contain any data someone might want in future? [18:09:02] maybe, but not very likely [18:09:28] SRE is planning to set up Sentry properly in Q1 or Q2 [18:09:48] it's on the list of jessie stuff, was wondering if someone might be interested in doing the stretch upgrade [18:10:47] given deployment-sentry is about puppetizing a 4 year old version, and now they have to kubernetize the current one, I don't expect a whole lot of overlap [18:11:00] ah [18:11:32] there's some value in getting it working just because people will probably work on the frontend logic before SRE sets up a proper Sentry server [18:11:54] so having it run in beta, even as an old version, would be convenient [18:11:58] I'll leave it be for a while [18:12:02] not worth much effort though [18:12:20] jessie is deprecated but should still be okay for another year [18:12:21] I'll see if the stretch migration can be done without issues [18:12:32] probably not until after the hackathon though [18:14:12] if they're going to put it in k8s then dont worry about it