[16:46:50] tgr_: thanks for starting that discussion. I think I generally agree that some other vetting beyond you and me is needed for handing a user the ability to collect oauth tokens that can edit site css & js. Or that we give up on patrolling the rights grants entirely. [16:48:05] For that particular use case I am a bigger fan of a bot account with self-OAuth as the way that on-wiki edits are made. That feels like it gives the local wiki better control in the event of misuse. [22:25:45] Are there any plans for when the class aliases that are deprecated and exist since 1.41 will be removed, e.g. \GlobalVarConfig? Based on past releases I assume this will happen before 1.45 is released, but the branch has been cut already and as far as I can tell they still exist on master [22:30:54] Usually when they're not removed they're still being used somewhere etc [22:31:02] Or have weird serialisation references [22:32:08] our rules tend to be more... when something can be removed, not when something will be [22:32:54] patches welcome ofc ;) [22:34:23] GlobalVarConfig seems to still be used in ~39 cases in our hosted extensions [23:49:57] As far as I'm aware the non-namespaced GlobalVarConfig is not used anymore in WMF-deployed extensions/skins, at least in the extension.json/skin.json files [23:51:08] I filed https://phabricator.wikimedia.org/T402038 a while ago and removed all usages [23:52:35] But I wanted to fix the usage of other class aliases that were supposed to be removed in 1.45 in 3rd-party extensions, when I noticed that they still exist in core right now for some reason, so I was just wondering at what point this removal usually happens [23:59:50] re "when something can be removed, not when something will be", I think that's in general a good idea, but in the past, class alias removals always happened 4 releases after they were deprecated, which makes it easier to tell when an extension is going to break