Staff Database Architect in SRE data persistence team in WMF. Used to be Wikidata software engineer in WMDE
I'm also open source enthusiast, mediawiki volunteer developer, and long-term Wikipedian.
All edits on tickets about databases are in my work capacity and anything else is in my volunteer capacity unless mentioned otherwise.
Babel: fa-N, en-4, de-2, tr-1, hu-1
I was asked to break this down to work that can be done in a quarter. It depends on the number of people being put on this but I give it a try here:
Possibly edit conflict. My bad :(((
Blocked until 1.39 branch cut.
Does centralauth get replicated to the cloud? I doubt that, let me check
True but since it's not a production issue anymore, I removed it as a subtask of train blocker + reduced its priority to High.
I enabled the addon to try the new TOC to give feedback. It generally looks nice but the interaction with sidebar is quite annoying atm, I was struggling to find TOC for a while until I realized it's fully hidden behind the sidebar that I keep open almost all the time (and I think it's my default).
Since the branch is not cut yet. I think we are out of the woods wrt the train but PageTriage being broken is something that needs fixing.
pingAll can be possibly cleaned up.
I can force-merge it later once there is no patch in CI (during weekend and quiet time) to avoid too much disruptions.
Sorry. https://www.wikibooks.org/ and the rest are not migrated to the new system and still use these terrible meta pages: https://meta.wikimedia.org/wiki/Www.wikibooks.org_template
I'm a big fan of this. This has been brought up as a confusing logic basically every time I ask developers what they find suboptimal in rdbms code.
My part for now is done.
There are probably some more deprecation warnings here and there. I took note and will make patches against in the parent ticket, FlaggedRevs is cleaned now.
The patch has been deployed. It should be fixed for now.
I might be missing some new updates but CN doesn't follow the train IIRC.
General notes:
I suggest going with zh-lta.wikimedia.org instead. That is more aligned with how we set DNS for misc projects.
LoadExtensionSchemaUpdatesHook hooks into update.php but we don't run update.php in production (it would bring everything down). That's for third party systems. We need to deploy this manually but Thalia done that before (you can do that on your own for creation of tables but for the rest a DBA has to do it, an example: T285149). If you need help in deploying it, let me know.
I ran the automatic upgrades in two eqiad hosts in s5, for one the db simply just refused to get back but that seemed to be the issue of the host being old/etc. but a powercycle seemed to fix the issue. The second one went fully smoothly and no issues so far.
I don't know how those work on top of my head but check how url shortener does it, it's also on x1. HTH.
public table as links tables are public as well.
Now we have auto_schema and it has been used quite often for schema changes (one being running as I write this). More info has been documented in https://wikitech.wikimedia.org/wiki/Auto_schema and there is a document on what would be the next steps and improvements on it https://docs.google.com/document/d/1qVinCcu4T5NkJneFKwY70giCDmP1kBhGee385LWdiwA/edit and next week we are giving a presentation about it. I think this can be closed now and we will be creating tickets for each needed improvement.
Yes. ORES is being moved to a new infra but that still doesn't fix the problem of ores not being able to talk to outside. Let's just call it declined.