In T219543#10855157, @Ladsgroup wrote:

In T219543#10854801, @Johannnes89 wrote:

There are some inconsistencies in the access labels – why is Special:Watchlist labled as "Restricted" while Special:Preferences, Special:GlobalPreferences, Special:ChangeEmail, Special:PasswordReset and a couple of other ones which are available to all logged-in users are labled as "Public"? See dewiki discusssion (I can file a separate ticket if this is out of scope for this task).

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

Sounds similiar to T389536: Selenium timeouts can cause the job to remain stuck until the build times out, which takes this for all extensions.

When getting upload warnings and stash errors with UploadStashBadPathException, the stash errors can be ignored.
In case of warnings from the api module the uploaded file is stashed (and can be seen at Special:UploadStash). This allows easier upload after warnings by providing the filekey and a better filename (for example).

Happens sometimes, T17430: Uploads sometimes are incomplete: file is there, but image page is missing / T393952

In T383171#10707671, @HCoplin-WMF wrote:

Closing this as Declined, given the abandoned patch. Feel free to reopen if you're still experiencing this issue or would like us to dig into it further!

That is a helpful feature when clicking throw a patch set.

The codesniffer is a tool for developer, it not running in wmf production. There is T266890 to discuss the release process.

Using the generator executes the requested api module and collects the pages, with this list the generator collects the data from all prop modules and combine it into a result.
The order is lost here to allow a better combine.
There is no way to preserve the random value from generator to the output.
Would say that this needs some work on how the generator collects data (ApiPageSet). Not very likly this feature can be implemented.

In T272803#10862867, @Nikerabbit wrote:

Lots of errors in the Translate extension now. How is one supposed to have comments like this now: https://gerrit.wikimedia.org/g/mediawiki/extensions/Translate/+/9d172de7d8a9fc802e403ddcce8a6b83050b415d/src/WebService/TranslationWebService.php#266? I could not figure any way to do it other than disabling the lint. The method itself has full type declarations so it doesn't need any function doc.

After fixing many of the non-static data provider in wmf-deployed code (T332865) I have tested PHPUnit on core. My demo patch can be found under https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1149986.
This should not block any other work to upgrade PHPUnit 10, feel free to start your own work, starting on my work or not, mention my work or not.

The linktarget view should get also an exists check on the new table. Append to the existing where: or exists ( select 1 from existencelinks where exl_target_id = lt_id )

The data for the data provider are stored in lua files. To access lua files a LuaEngine is needed. To create a LuaEngine some non-static parts of the test case are used/needed, to get engine name or for a template callback.

Sorry for the confusion, I have read the task description as there was a problem with the captcha backend and moved the tasks to the ConfirmEdit board and also marked it as production error.

CentralNotice is special about deployment, see T179536: Unexpected side-effect of CentralNotice wmf_deploy branch strategy

Seems related: T393963: PHP Deprecated: Use of $_SESSION was deprecated in MediaWiki 1.27. [Called from session_write_close in (internal function)]

Your SQL indicates you want all category member of that category, but https://en.wikipedia.org/wiki/Category:A-Class_Austria_articles has no articles in it.

Happens sometimes, see T17430: Uploads sometimes are incomplete: file is there, but image page is missing

Chould be the result from https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1140725 / T362324

Linking your change: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1143959

It is for the same reason invalid as T393824: Mediawiki/includes/http not compatible with psr/http-message version 1.1

In T393824#10809794, @Reedy wrote:

Does the extension explicitly want 2.0, or is it just a loose dependancy that results in it picking the highest versions or can?

The error is about return type declarations resulting in a mismatch for the function signature.

Created a patch set to move the mocks into it's test function as a "quick win" (as this is only low priority and maybe fall out some day of the work queue)