OK, so AIUI remaining work here on this task:

• Backport 704745 and 1220366 to REL1_44, REL1_43 (REL1_45 already done in [original patch and [https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1224160|1224160]] respectively).
• For each version of MW,
  • Make a release of Parsoid with the above patch
  • Pull the new release into MW core and MW vendor
  • Apply the patch for T413573 for core
  • Apply the corresponding patch(es) for extensions/skins, once they exist, that are in the tarball.
• When the next Quarterly release of MW happens, announce PHP 8.4 being supported, and (only then) adjust the on-wiki claims about PHP 8.4 support.

In T411722#11513735, @Quiddity wrote:

In T411722#11512828, @Jdforrester-WMF wrote:

• Talk to @Quiddity to see if there's an existing worklist of stuff to stand up a new community wiki. Esp. "pages that a wiki needs to have".

I've taken my old list from Wikifunctions's early days, and made a more generic version at https://meta.wikimedia.org/wiki/User:Quiddity_(WMF)/List_of_initial_wiki_pages -- Edit/relocate/etc as desired.

Yes, Q1988.

Quick notes, to turn into sub-tasks:

Deprecation landed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1130614 which went out in 1.44.

Ha, I made it emit deprecation warnings in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/951999 back in REL1_41, and am now working on its removal. Let's call this done, as-written.

Ha, I made it emit deprecation warnings in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/951998 back in REL1_41, and am now working on its removal. Let's call this done, as-written.

Looks like the two landed ones have been pulled into wmf_deploy in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/1223689 but the third, just merging, isn't yet.

This has been deployed, e.g. https://codesearch.wmcloud.org/search/?q=internalAttemptSave&files=&excludeFiles=&repos= no longer returns results from that repo.

Thanks for the write-up, Alexandros — it sounds like there was a fair bit of discussion in Lisbon; sorry we missed it. We've given our quick thoughts inline. It feels like there's a lot of confusion here. Perhaps we should discuss this in the Performance working group every second Monday?

In T414181#11506963, @GrounderUK wrote:

In T414181#11506909, @Jdforrester-WMF wrote:

The problem here is that the orchestrator entirely ignores the on-wiki version of pre-defined persistent objects (ZID < 10k). I'm not sure we want to re-open that performance issue?

Maybe not, but we do want Z828 to do what it is designed to do. It works for Z60s, so I don’t think it’s a problem with all pre-defined Persistent objects, just Types.

I don't think this should be marked as a duplicate of T412952, which is a time-bound piece of work that might or might not accomplish all of this Epic?

The problem here is that the orchestrator entirely ignores the on-wiki version of pre-defined persistent objects (ZID < 10k). I'm not sure we want to re-open that performance issue?

In T386108#11504541, @A_smart_kitten wrote:

Ah, sorry - thank you for correcting me :)

T409283 isn't fixed until the patch is in a release that is pulled through, tested, and confirmed.

Sadly php-ast is at 1.1.2 for trixie (and even sid), so this'll need some local over-ride work: https://packages.debian.org/trixie/php-ast

In T361748#10969902, @Tgr wrote:

Generally with includes/libs the assumption is that each directory will eventually be spun out into a standalone library (at which point it needs separate i18n files).

This has now gone live in production with the MediaWiki train; please check and confirm if it's fixed the issue.

This has now gone live in production with the MediaWiki train; please check and confirm if it's fixed the issue.

In T409229#11502884, @GrounderUK wrote:

A quoted reference still fails to reach Python or JavaScript code.

For example, in this call the two elements should be equivalent but the second causes a failure that does not occur when it is deleted from the list. The failure is equally apparent with a call using Python echo (Z15788) but there is no link available for such a call. Test case Z31006 demonstrates the failure but is not connected: “Unspecified error (error information: "&#39;str&#39; object has no attribute &#39;get&#39;")”. The JavaScript failure with Z10015 is: “Invalid executor response (contents: "[2026-01-08 11:14:38.395] [error] execution failed: out of bounds memory access, Code: 0x408 [2026-01-08 11:14:38.395] [error] When executing function name: &quot;_start&quot;")”

Train blocker -> UBN!.

Moving the scary rights away from Maintainer to the more common (and available!) Functioneer status is a big change, and should go through a proper product/community lead discussion before we think about doing this!

I've made this a direct child of T412953, but perhaps it should be elsewhere in the tree?