[13:38:29] <Lcawte>	 Is there a page that documents what versions are too old to update.php?
[13:44:19] <Reedy>	 It is documented somewhere...
[13:44:55] <Reedy>	 https://www.mediawiki.org/wiki/Manual:Upgrading#How_do_I_upgrade_from_a_really_old_version?_In_one_step,_or_in_several_steps?
[13:53:52] <Lcawte>	 Thanks! I guess that means 1.35 is the version to keep an instance of somewhere for now.
[15:09:33] <jfolv>	 What handles updating the Recent Changes table after an edit is made? Is it a job? Or is it just an asynchronous query that runs during the request? I'm still trying to debug my issue with edits sometimes not showing in the RC, and I notice that a large page will save the edit and return before the edit appears in the RC. Sometimes it takes upwards of 30 seconds for the edit to appear.
[15:10:33] <jfolv>	 I'm desperately trying to find some way to reproduce the issue without turning on $wgDebugLogFile because our backends are auto-scaled and it would immediately try to log far too many requests too quickly.
[16:02:37] <ashley>	 jfolv: I'm not sure why that'd happen; there seems to be a job in /includes/recentchanges/RecentChangesUpdateJob.php as of MW 1.43 (interesting, since most if not all other jobs are in includes/jobqueue/jobs/ dir) but it seems to handle only purging "expired" rows from the recentchanges DB table and updating active users info
[16:09:18] <MatmaRex>	 jfolv: with https://www.mediawiki.org/wiki/Manual:$wgMWLoggerDefaultSpi you can configure debug logging much more selectively
[16:10:00] <MatmaRex>	 better docs here: https://www.mediawiki.org/wiki/Manual:MonologSpi.php#Usage