[03:25:41] legoktm: installer overrides (mw-config/overrides) are pretty much a worst case scenario for changes and deprecation [03:26:33] I gather the idea is that shared hosting providers are encouraged to subclass CliInstaller by dropping in private code [03:56:32] TimStarling: kinda yeah, I don't think we really thought about that when it was introduced in 1.27...the recommendation prior to that was to just patch the installer manually [03:56:57] the Debian package does https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/debian/+/master/debian/DebianOverrides.php - it used to be much worse before my PlatformSettings.php RfC [04:17:15] the idea is to have e.g. php install.php --skins=Vector --extensions=AbuseFilter,ParserFunctions [04:17:32] as long as the list can be empty then it will solve T187287 well enough [04:17:33] T187287: CliInstaller: Allow turning off auto-enabling of skins and extensions - https://phabricator.wikimedia.org/T187287 [04:38:20] TimStarling: that seems reasonable, are you worried about making a breaking change to the PHP interface? [04:39:44] I'm pretty much done with that change, without making any breaking changes, it was just a nuisance having to keep backwards compatibility [04:40:46] it makes every change harder [13:57:02] legoktm: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/460436 should probably have had some sort of CI failure for having both "includes/edit/" and "includes/Edit/" directories. Which project should I tag that task with? [13:57:53] nasty [13:58:43] anomie: #ci-config probably, since we're going to want such a check across all repos somehow [14:01:10] Ok, T204824 [14:01:10] T204824: There should be a CI check for files differing only by case - https://phabricator.wikimedia.org/T204824 [15:28:16] hmm aparently there's missing i18n for flow-error-fetch-after-open-lock in flow [15:33:05] filled https://phabricator.wikimedia.org/T204831 [20:14:42] Reedy: Because you love me, here's a fun hit-list: T204863 [20:14:43] T204863: Drop legacy deprecated code from MediaWiki ahead of MediaWiki 1.32 release - https://phabricator.wikimedia.org/T204863 [20:17:11] :P [20:50:34] legoktm: https://codesearch.wmflabs.org/search/?q=LoginForm&i=nope&files=&repos= [20:50:48] somehow core is labeled as extensions/ChangeUserPasswords [20:51:22] tgr: someone imported core into that repository [20:51:23] ...or does that extension actually duplicate half of core? [20:51:50] It does. [20:52:14] We should probably delete the repo and re-create it to avoid having a huge git history. [20:52:27] And a load of extensions [20:52:27] https://phabricator.wikimedia.org/T202275#4594776 [20:53:02] But… effort. [21:01:06] * Hauskatze archiving OCG-related stuff [21:30:57] Reedy, what does "1.29 was due to be previously announced as end of life" mean? [21:31:09] It was supposed to be dead months ago [21:31:09] someone forgot to announce EOL? [21:31:14] But we never formalised it [21:31:19] :| [21:31:20] Because we were waiting for the "next release" [21:31:26] For six months. :-( [21:31:29] For maintenance and security stuff [21:31:30] ala https://phabricator.wikimedia.org/T197669 [21:31:44] Not 6 months [21:31:48] ~3 now [21:31:58] should we not pre-determine EOL dates from release? [21:32:00] End April -> end September is five months, sorry, you're right. [21:32:15] Krenair: Well, they are [21:32:20] [22:31:17] Because we were waiting for the "next release" [21:32:24] Yup. [21:32:28] https://phabricator.wikimedia.org/T197669#4315359 [21:32:29] they are pre-determined, but we wanted to give people another release before doing so to ease transitions [21:32:40] And even more so with patches having been backported [21:32:41] then, life [21:32:43] Releasing is hard and sucks a huge amount of energy from actually fixing broken things. [21:32:46] The real problem here.. Is the security release is late [21:32:55] Which we know is a problem, and has been a while [21:32:59] that ^, which we should automate the ef out of :) [21:33:08] But yeah, life and slightly more important things [21:33:16] * James_F hugs the wonderful RelEng and Security teams. [21:36:32] I do love all the auto replies from various ticket management systems for sending a mediawiki-announce email [21:47:35] * James_F grins. [23:52:26] tgr: Sorry for being a stickler re. setPassword(). [23:53:27] thanks for checking [23:55:19] why are we using DisableAccount again? I thought that was superseded by $wgBlockDisablesLogin [23:56:43] Because legacy [23:56:45] It is, mostly [23:56:58] log entries I think was the issue with the migration script [23:57:15] https://phabricator.wikimedia.org/T141954