Does --dbssl not work? I added that option in 914882.

Let's reflect the status quo with https://gerrit.wikimedia.org/r/c/mediawiki/tools/phan/SecurityCheckPlugin/+/989246 being merged (or does that completely resolve this task?)

Removed in rMW3f9d716653fd0ff123e624931fb3b3e6bb09f0d2.

Hmm, the reason BackupDumper (and by extension MediaWiki-extensions-DumpsOnDemand) uses newMainLB is because of rMW506a19b7af78: Cleanup live hack from wmf-deployment r53208 a bit: DB selection using load… (r56347), where it mentions that not doing this might "have caused problems when we were fetching other things from the local database in the middle of an export". For MediaWiki-extensions-DumpsOnDemand, the release for 1.41 uses IConnectionProvider, which performs as proposed. I'm not sure what the impact would be, but given that IConnectionProvider does not have special handling for this (and the underlying internals have been greatly overhauled since 2009), I suspect this should be harmless. I'll create a patch for DumpsOnDemand for MediaWiki 1.40, which I'll backport to 1.39 for posterity, as 1.41 has not yet been released.

As an example, use: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/937192.

What is the value of the Foo message (MediaWiki:Foo)? If it doesn't exist, ⧼Foo⧽ will be shown to indicate that the message is missing.

Is the alternative in the third good thing T290932?

Looking at the error log the following line seems suspect:

RequestFromGlobalsTest has a setServerVars helper that modifies $_SERVER. It is not cleaned up after the test, which causes issues when MediaWikiTest tries to use it.

It didn't so much as stop as it never actually started. If you check the logs, then you will see the following:

Note that the Bugzilla phabricator mapping isn't 1 to 1, Bug 1 is T2001. Bug 666 would be T2666.

Is this about https://github.com/stanolacko/LinkAttributes/? If so, you should post the patch there (as a pull request or as an issue), as the extension doesn't use Gerrit for version control or Phabricator for tracking tasks.

MediaWiki-Vagrant Buster now has a separate role for phan that installs php-ast: T321987: Create a separate role for phan that also increases the memory limit, the scripts are no longer necessary.

In T321984#8354942, @Mainframe98 wrote:

If anyone wishes to do this themselves, these links might help you: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes, https://developer.hashicorp.com/vagrant/docs/boxes/base

(https://salsa.debian.org/cloud-team/debian-vagrant-images too)

I split the patch into two parts, mostly because I'm not very familiar with node/npm in Vagrant. I think the complexity came from the whole, "node is outdated but things rely on outdated npm" debacle, so be sure to test if it actually works. It provisions at least.

I'm experiencing T338356: Vagrant fails to create apt.conf.d/01no-recommended during setup and couldn't find a fix. It turned out to be easier to just convert to bullseye. It would be great if we could get a separate branch to use while we wait for production to move to bullseye.

Somewhere along the introduction of run.php this appears to have been resolved. (Tested on rMW44504ffaff7933ff638f5bb0dd62bb253970f78b)

I0ce7c2cd3eed958bb99f1a2e7c4a45c51668869d takes a different approach: check the password before creation. This will only fail like mentioned in the description when the groups added have a different password policy than the default. That should be rare: most times those group changes happen on-wiki to record them in the logs.

I'd noticed that too. Maybe just print a warning then? Or generate a valid password and print that perhaps, although given the flexibility of password policy requirements, that might not be achievable.

For T21157, the description matches:

Is T335995 similar? I can't tell if here the repository suddenly travelled back in time like what happened to mediawiki/core in T335995.

It would be the first PHP extension that isn't bundled with PHP on Windows. Given that PECL doesn't offer new Windows DLL's anymore, this would (in the future) make using MediaWiki on Windows more difficult. The compilation process on Windows isn't easy either.

Exciting! I'll give that a try, thanks!