Change #1104680 had a related patch set uploaded (by Abaris; author: Abaris):

[integration/config@master] zuul/layout.yaml Add mediawiki/libs/ParamValidator

https://gerrit.wikimedia.org/r/1104680

Change #1104680 merged by jenkins-bot:

[integration/config@master] Zuul: [mediawiki/libs/ParamValidator] Add mediawiki-php-library CI

https://gerrit.wikimedia.org/r/1104680

Mentioned in SAL (#wikimedia-releng) [2024-12-16T18:04:48Z] <James_F> Zuul: [mediawiki/libs/ParamValidator] Add mediawiki-php-library CI, for T382170

Change #1116517 had a related patch set uploaded (by Abaris; author: Abaris):

[mediawiki/libs/ParamValidator@master] Set up ParamValidator library

https://gerrit.wikimedia.org/r/1116517

Change #1116517 merged by jenkins-bot:

[mediawiki/libs/ParamValidator@master] Set up ParamValidator library

https://gerrit.wikimedia.org/r/1116517

Just noting that I feel like it may be a bit annoying / confusing for future git blame-ing that (e.g.) the blame within the new repo for the ExpiryDef::isInMwRange function now points to 'Set up ParamValidator library' , rather than 'ParamValidator: reject expiry dates that don't fit in 14 chars'.
(This is speaking from personal experience just now, when I didn't realise that the library still existed within MW core [and so was checking the git blame for mediawiki/libs/ParamValidator], and was trying to figure out why that function was added as part of setting up the new ParamValidator library.)

I wonder if anything could be done about it at this stage? I kinda wonder whether just importing the files to the new repo without their git histories (and including a pointer in the commit message to their original location) would be less confusing than having the diff for a number of changes point back to a commit that doesn't explain why they were made / doesn't point back to the original commit and/or repo-file they were made in.

(ccing @Jdforrester-WMF for your info)