[16:20:48] I'm not exactly sure what's going on with the test failures in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/720436.. I guess it doesn't like that the new aliased class is loaded via AutoloadNamespaces and not AutoloadClasses? [16:22:28] Yeah [16:22:49] You'll need to add the namespaced and the non namespaced version to AutoloadClasses until you remove the aliases [16:23:12] (if you keep them in the same files) [16:24:00] Also, you've got them the wrong way round [16:24:07] And you can use ::class [16:24:35] class_alias( LocalUserMergeJob::class, 'LocalUserMergeJob' ); [16:26:18] they're not wrong way around, the namespaced version can't be used before it's live on all wikis so that patch adds the namespaced version as an alias of the non-namespaced one, and the next one flips it around [16:27:17] Why do it like that? [16:27:27] You can namespace them, and add the back compat aliases... [16:27:45] AFAIK it's worked fine when we've done it elsewhere [16:28:51] so that things don't break when metawiki creates jobs with the new namespaced name while enwiki is on the previous train [16:32:36] unless I'm missing something, not doing that risks job being run with a non-existent namespaced class name [16:34:06] Tell people not to rename for a few days? :P [16:35:07] someone is going to miss that, and then I'm going to get yelled for blocking the train [16:35:29] It wouldn't be a train blocker [16:35:40] At worst, the local jobs on the wiki would fail, and may need someone to run a shell script [16:35:51] But then, it's not like renames are 100% reliable anyway [16:36:18] But yes, I think you're right about the plan *should* prevent some problems [16:37:28] Just obviously need to be careful when each patch is merged [16:45:59] yeah [16:46:55] I'll probably just wait until the 1.37 cut before merging even the first one, just makes it much easier if you don't have a release branch in an inconsistent state