[04:56:07] AaronSchulz: hey, not sure I understand the question. are you asking how to use it locally from git, or what the steps for the release commit are`/ [04:57:07] using it locally from git, you can run ./bin/fresh-node* directly without the installer, or (if you set version to a recent commit and update hashes with debug command) then you can run the installer locally from git to copy them to your global bin [04:57:15] release steps are in the repo markdown file [05:06:33] zabe: re T414016 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1224171, I was half-way creating a follow-up that adds a CACHE_VERSION constant to the Flags class itself to improve discovery of this in the future. As-is it seems likekly to happen again in the future. [05:06:34] T414016: PHP Deprecated: Creation of dynamic property MediaWiki\Extension\AbuseFilter\Filter\Flags::$suppressed is deprecated - https://phabricator.wikimedia.org/T414016 [05:06:56] But there's more than one class involved. The serialised object is an array of Filter objects, whichi extend AbstractFilter and involve other classes of which Flags is only one. [05:07:18] So it's not as simple as just that one class. Which makes me think.. maybe this shouldn't be stored as serialised php objects? [05:07:51] the getAllActiveFiltersInGroupFromDB function looks quite close to a pure data retreival already, its only the last line that turns the rows into an object tree. [05:08:28] assuyming that construction is cheap, perhaps that's a natural divide we can move up slightly to outside the WANObjectCache/getWithSet barrier so that we're caching the rows instead of the constructed objects. [05:08:50] then the data format and retreival are both owned by the FilterLookup class and so you can have a CACHE_VERSION constant there instead. [05:09:03] wdyt? [05:17:21] Krinkle: I'm talking about the process for making a release. Is there something blocking it? [05:17:42] * AaronSchulz was also curious if he missed something [05:27:29] no [18:05:56] Krinkle: Flags and Specs look like they could easily be converted to use json serialization instead of serializing them as php objects [18:06:58] once that is done, doing the same for Filter seems reasonable I think [18:07:59] the contruction does not look very expensive (without having done any benchmarking) [22:53:48] Reedy: q: do we backport composer package upgrades that fix PHP deprecation warnings? [22:54:20] We will usually try, yeah [22:54:36] but bare in mind you've gotta do the vendor bumps which don't have CI on REL1_XX [22:55:33] (is that saying that WMF CI won't tell you whether all the tests will pass with the upgraded dependency?) [22:55:54] Depends what exactly you're bumping [22:56:56] Stuff in an extension or core can depend-on a vendor patch [22:57:04] fair enough, right now i'm looking at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1098599 which (from git bisect locally) fixes a "Constant E_STRICT is deprecated since 8.4" warning from PHPUnit (which occurs on REL1_43 currently for me) [22:57:22] aha [22:57:43] phpunit isn't in vendor, so that should be a relatively trivial backport [22:57:52] But yeah, definitely [22:58:24] then also on REL1_43 i got "Function curl_close() is deprecated since 8.5" from guzzle-http when running `composer mw-install:sqlite` (but i haven't tried to bisect that one yet) [22:58:37] so i guess i'm interested in those specifically, but also very much in a general sense :) [22:59:20] In practice, people shouldn't be running with deprecated warnings in production [22:59:25] But people like bluespice do develop against LTS [23:00:24] So I'm guessing they'll appreciate it [23:01:12] fair enough :) i guess my worry would be in case i was gonna propose a composer upgrade to be backported, and it turns out that it has some b/c break for that branch or something [23:01:35] The problem will start to become when guzzle is needed by other libraries, so you need to bump versions there etc [23:02:10] https://github.com/guzzle/guzzle/releases/tag/7.10.0 suggests PHP 8.5 support [23:02:37] Certainly do file tasks if they're not trivial backports, so someone can come back to it too [23:03:26] 'The problem will start to become when guzzle is needed by other libraries, so you need to bump versions there etc' hmm, yeah... [23:04:08] or things guzzle depends on... [23:04:11] start stacking the turtles [23:04:52] If something is explicitly broken on a version of PHP we're supposed to support, that's obviously more important [23:05:10] indeed [23:05:25] deprecated is a bit more best effort [23:08:28] re the phpunit upgrade specifically, given that it was what prompted me to ask, are you saying that it should be fine if i cherry-picked that in gerrit? (it'd just make running tests on REL1_43 a bit less spammy fwiw) [23:08:40] Yeah [23:09:03] obviously it'll complain about the conflicts, but you can just delete the RELEASE-NOTES change [23:09:12] if you're lucky, composer.json won't conflict ;) [23:09:24] oki, let's see [23:09:45] you can also do git review -x 1098599 locally if you want to do it there [23:12:04] did that (ty), turns out there is a composer.json conflict, let's fix that [23:12:57] actually wait no there's not i misread it. it was complaining about the 1.44 release notes [23:13:09] heh, git rm it [23:16:35] damn, i can't add a "(cherry-picked from commit" line at the bottom of the commit message w/o git-review generating a new change id [23:16:36] ah well [23:17:42] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1224828 [23:19:49] Don't worry about that bit [23:20:04] yeah i know, i just personally like it lol