[00:02:03] <TimStarling>	 I was not aware of it
[00:03:34] <AaronSchulz>	 the caching could boost save times...but the change was reverted like 3-4 times due to different bugs. Last I checked, vvv wanted to run a script to compare old vs new AF results for historical (recent changes entries) edits.
[00:03:56] <AaronSchulz>	 looks like some bugs are still open, but if those were fixed, and the results matched, then it could be reasonably tried again.
[00:04:36] <TimStarling>	 so it mostly needs review? shepherding?
[00:04:50] <TimStarling>	 or does someone need to do development work?
[00:07:18] <TimStarling>	 btw, did you see https://gerrit.wikimedia.org/r/#/c/351759/ ? This is a 2-line patch to EtcdConfig, very easy if you want to review it
[00:19:13] <AaronSchulz>	 it needs some bug fixing and testing
[00:19:24] <AaronSchulz>	 the bulk of the coding is done though
[00:19:44] <AaronSchulz>	 vvv seems kind of busy, so I think it will need a bit of coding for the fixing instead of just reviewing fixes
[00:20:07] * AaronSchulz looks at that patch
[02:24:40] <Krinkle>	 https://gist.github.com/Krinkle/99bbdf9bc710ae125b9f96e0b848de55 - MediaWiki hotspots in the code according to bugspots
[02:24:57] <Krinkle>	 based on commits that claim to 'fixe(s)/close(s)' things
[14:06:46] <Reedy>	 Krinkle: lol
[14:07:00] <Reedy>	 Can ignore /i18n/*.json... And hooks.txt
[18:20:37] <Krinkle>	 Reedy: hooks.txt not per se, while that file itself won't contain "bugs" (aside from minor doc issues) - it does indicate that very often bugs are found in the processing of hooks. Whether it is adding a hook and then reverting it again, or changing the signature etc. Fact is, many bug fix commits ended up also changing something in hooks.txt which is a nice
[18:20:37] <Krinkle>	 proxy.
[18:21:36] <Krinkle>	 And it's interesting to see EditPage and Parser high up. Despite those files being scary, doesn't safe them from being broken/fixed a lot. 
[20:21:44] <Krinkle>	 Reedy: https://gerrit.wikimedia.org/r/#/c/352229/1