[12:40:27] Krinkle: do you think https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1091922 is a sane approach? There was a push at some point to replace dynamic PHP generation of settings with YAML files, and this would make that harder. Not sure if that was completely abandoned or is still planned. [13:09:54] tgr|away: I don't think there's likely a future there. More useful in the short-term is getting to a state where config is easy to maintain and read (i.e. static arrays but in PHP form so that we benefit from using constants and `::class`, benefit from using number/string/array syntax that matches PHP familiarity, and benefit from opcache), which is something we've done for numerous settings already (e.g. the ext- and core- files in [13:09:54] wmf-config). [14:20:00] Thanks. So I take it making wiki tags (but not the settings themselves) more dynamic would be acceptable then. [14:35:31] tgr|away: technically for the runtime, yes. I'm less sure of the implications on validation and dev exp, though. Left a comment at https://phabricator.wikimedia.org/T373737#10331184 [14:36:34] perhaps some kind of naming scheme that sets it apart from dblists would help, like '#isSharedDomain`, as a layer after default/tags/wikiids. [14:37:02] but depending on how many overrides we actually need (fewer than with loginwiki I assume), holding it together in CS.php might work too? [14:54:09] we could definitely do it in CS.php but I think it would be worse for developer experience. There would have to be an extra condition check for each extension loading (since you cannot unload them once you loaded, so no way to do that all at one place), plus a block that overwrites settings from InitialiseSettings etc; the existence of that block wouldn't be easier to become aware of than the [14:54:15] existence of a magic DB tag (which I agree is problematic for DX) [14:54:44] I was thinking of creating a new DB tag ('auth'), creating a fake dblist file, and using it for documentation [14:55:46] you are also correct that shared caches (or databases) can become a big problem if this is overused to significantly diverge the normal and shared-domain version [14:56:45] I was thinking that just disabling extensions is safe (most of the other changes are not important), but I can imagine issues where an extension uses hooks to e.g. modify what gets written into parser cache [14:57:42] anyway I'll follow up on the task, probably better place to discuss