[00:00:34] the touched timestamp has to be greater than the skewed timestamp [00:01:15] but anything that updates the touched timestamp will apparently also queue refreshLinks jobs, and deduplication will kill the original job with the relevant skewedTimestamp [00:01:35] so it seems like the parser cache won't ever be used [00:07:22] afaik, <<$page->getTouched() >= $skewedTimestamp>> was added to avoid high i/o between runners and pc100* [00:08:21] not ever using the parser cache would certainly achieve that... [00:08:24] ideally that would just check when the options key was generated or something [00:08:37] (something small) [00:09:42] now that LinksUpdate is unconditionally enqueued, it means there will unconditionally be a second parse operation done by the job runners after every save [00:18:37] <<$page->getTouched() >= $this->params['rootJobTimestamp']>> seems more useful [00:18:47] all this could use wfDebugLog() in any case [00:22:12] or statsd [15:12:10] Sigh, https://bugs.debian.org/822807 [19:56:36] i changed my password, just in case to something even more different [19:56:37] now i can't login on test.wikidata, though maybe i am confused [19:56:53] aude: No changes to authentication. I did see some PasswordExceptions in the logs this morning. [19:56:59] i am doing "forgot password" now [19:57:18] i don't know what reason $4 is [19:57:38] and if somehow i triggered one of the reasons (though my password was quite long and complicated :) [19:57:40] It's also unlikely that "Passwords must be at least 1 character" should really be showing up there. [19:57:47] at least 1 character [19:57:49] at least 8 characters [19:58:29] my staff account does not have any issues with logging in [21:36:16] 10MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown, 10Phabricator, 06Project-Admins: Allow to search tasks about MediaWiki core and core only (create MediaWiki umbrella project?) - https://phabricator.wikimedia.org/T76942#2261814 (10Luke081515)