[01:00:38] Krinkle: there's a trait that tgr wrote to help do hard deprecation of class members [01:01:27] Krinkle: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/master/includes/debug/DeprecationHelper.php [01:08:25] legoktm: OK. I assume then that means the task I ref'ed is no longer valid. [01:08:53] T71939 [01:09:45] T71939: Deprecate direct access to class variables - https://phabricator.wikimedia.org/T71939 [01:10:01] * Krinkle signs off [14:42:26] <_joe_> hey, I have a question regarding schema change management in mediawiki. Specifically, schema changes need to happen asynchronously from code deployments, as they take a long time to apply [14:42:48] <_joe_> how do we manage that? Do we just ensure new code can work with or without the new piece of the schema [14:43:14] Pretty much [14:43:15] <_joe_> or do we do something fancier? [14:43:17] <_joe_> ack [14:43:17] And/or add a feature flag [14:43:27] <_joe_> yeah I thought it would follow [14:43:42] We don't tend to do index exists, or col exists in prod code, so a feature flag usually is used [14:45:17] Feature flag means the code can be merged rather than the code changes and the schema changes in different patches, and will get some testing on dev wikis etc too [15:19:44] _joe_: Yes, usually a feature flag. That's what we did with the recent `comment` and `actor` changes, as well as the changes for MCR. The other popular method is to merge a succession of patches that work the same as progression of a feature flag: one to add the new schema, then wait for the DBAs to make the change, then one or more to roll out using it (and stop using the old), then another to drop the old schema. The feature flag approach has [15:19:44] the advantage of allowing more gradual roll-out than just riding of the train, with the disadvantage of some added code complexity in maintaining multiple code paths during the process. [15:21:18] <_joe_> I got to that tangentially while thinking about https://phabricator.wikimedia.org/T220246 [15:21:25] <_joe_> which regards cassandra [15:21:38] <_joe_> and more the management of the schema than how to apply it [15:21:52] <_joe_> but I do think the two things are pretty much tied together [15:27:16] _joe_: Looking at that task, what you describe in "Schema Management" is about what MediaWiki does for the SQL schemas too: we have the DDL to initially setup everything in maintenance/tables.sql (and maintenance/postgres/tables.sql, maintenance/mssql/tables.sql, and maintenance/oracle/tables.sql; see also T191231), and code for applying alters in maintenance/archives/ (and maintenance/sqlite/archives/, etc) and corresponding code to determine [15:27:16] which ones actually need to be run during update.php in includes/installer/*Updater.php. [15:27:18] T191231: RFC: Abstract schemas and schema changes - https://phabricator.wikimedia.org/T191231 [15:31:04] In Wikimedia production, thought, we don't use update.php as the scale of our data would make it take far too long (on the order of days or weeks) and would likely lock the wikis for much of that time. The schema changes are managed by the DBAs, while configuration changes and maintenance script runs (e.g. for back-population) are handled by the developer. [15:35:58] <_joe_> ack, that was more or less what I understood [17:58:09] Recently, I've seen that calls to hard deprecated methods causes Jenkins to fail. This is intended right? I'm not aware, just noticing, thanks! [18:13:00] James_F: Per T221431, do you think we should also hard deprecate SearchEngine::replacePrefixes()? It's similar to the one on that task. [18:13:01] T221431: Actually (hard) deprecate SearchEngine::transformSearchTerm and remove - https://phabricator.wikimedia.org/T221431 [18:13:08] If so, I can file a task and handle it [18:38:14] xSavitar: That's what hideDeprecated( 'FunctionCallHere' ) is to suppress [18:40:45] Reedy: Thanks, a quick search on my IDE seems it's used only in tests? [18:41:03] Right [18:41:25] But a patch is up for some lax about this as well: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/505278 [18:41:30] Generally, we try and make sure all WMF deploy extensions (etc), if not all hosted extensions don't call them before hard deprecating [18:42:15] Okay [18:46:38] Sometimes it happens [18:46:48] Sometimes we have to revert these patches cause they cause too much spam [18:47:19] :)