In T175146#9712693, @daniel wrote:

Why do you think that endpoint should be removed first? I thin the order doesn't matter...

What I am trying to figure out right now is how we can send API requests to the correct domain. rpc/runSingleJob.php looks at the "databas" field of the payload and then uses MWMultiVersion::getMediaWiki to initialize the correct wiki. If we use the RESt API, we have to use the Host header instead. Or we send some other header, like X-Wiki-Name, that gets interpreted by MWMultiVersion::getMediaWiki.

In T175146#9711987, @Krinkle wrote:

@daniel Is the REST API safe to remove from the EventBus extension? We may want to do that first.

@daniel Is the REST API safe to remove from the EventBus extension? We may want to do that first.

Change #1019399 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] WIP: add a REST endpoint equivalent to SpecialRunJobs.

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

Change #1019398 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] WIP: add REST handler for running a job

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

In T175146#9710653, @Krinkle wrote:

@daniel Are you thinking about IP subnets as protection mechanism because you prefer it, or because you think it's what we use today? Of the 5 job runners in the task description, number 4 used this mechanism. However that one (runJobs.php) has not been in use for several years. I've updated the task description to clarify this.

@daniel Are you thinking about IP subnets as protection mechanism because you prefer it, or because you think it's what we use today? Of the 5 job runners in the task description, number 4 used this mechanism. However that one (runJobs.php) has not been in use for several years. I've updated the task description to clarify this.

Quick brainstorming:

We've begun the migration. For bugs and enhancements, see MediaWiki-libs-Stats

This needs discussion with someone from service ops about how to safely expose RunSingleJob as a REST endpoint, so it does not become publically accessible.

Tagging MWI for triage/planning

This was fixed in T244492

Change 1009784 had a related patch set uploaded (by Ahmon Dancy; author: Ahmon Dancy):

[operations/puppet@production] mw-xml.sh: Update maintenance script

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

After deploy of next week, I will run lsc 😈

Change 982929 merged by jenkins-bot:

[mediawiki/core@master] Move Parser to Mediawiki\Parser namespace

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

Change 997927 merged by jenkins-bot:

[mediawiki/core@master] Move hooks used by OutputPage into includes/Output/Hook

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

@phuedx is there a newer ticket we could merge this into?

Change 997927 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Move hooks used by OutputPage into includes/Output/Hook

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

Change 995123 merged by jenkins-bot:

[mediawiki/tools/phan/SecurityCheckPlugin@master] Add compatibility for Parser namespacing

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

Change 995123 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):

[mediawiki/tools/phan/SecurityCheckPlugin@master] Add compatibility for Parser namespacing

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

Also, from the convo in December's tech leadership CoP meeting, I started thinking about how what we want for T291120: MediaWiki Event Carried State Transfer - Problem Statement is pretty similar to what is in MW's logging table, except we need the data to be structured, comprehensive and consistent (meaning no missing state changes). In T120242: Eventually-Consistent MediaWiki state change events | MediaWiki events as source of truth, one of the solutions outlined is the 'Transactional Outbox' pattern, which is kinda similar to a comprehensive+structured logging table from which we can generate and externalize state change events. I betcha we could tie these ideas together somehow.

It seems to me that Symfony's event system is close to what we want to aim for: https://symfony.com/doc/current/components/event_dispatcher.html. Symfony also has mechanism to integrate "events" with async message queues: https://github.com/php-enqueue/enqueue-bundle

Change 358164 abandoned by Thiemo Kreuz (WMDE):

[mediawiki/core@master] Make talk namespace optional [DNM]

Reason:

It's probably impossible to rebase a 6 year old patch that's that big. It can still be referenced and is still linked from the ticket.

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

Change 982929 had a related patch set uploaded (by Subramanya Sastry; author: Subramanya Sastry):

[mediawiki/core@master] WIP: Move Parser to Mediawiki\Parser namespace.

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

(making the child ticket part of codejam)

Change 551346 merged by jenkins-bot:

[mediawiki/core@master] Remove support for extensions requiring a MW version via Composer

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

Change 551346 merged by jenkins-bot:

[mediawiki/core@master] Remove support for extensions requiring a MW version via Composer

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

In T249573#9388985, @CCicalese_WMF wrote:

I propose that we rename this task to: "Remove support for specifying a MediaWiki version in an extension/skin composer.json" and make the Motivation in the task description consistent with that.

The final extension (SimpleBatchUpload) that was found in codesearch to be using the feature being removed by the patch is now no longer using it.

See T351411#9338177 for some scenarios

Change 976311 merged by jenkins-bot:

[mediawiki/core@master] Namespace remaining files under includes/deferred

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

Change 976311 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Namespace remaining files under includes/deferred

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

per mw:Maintainers.

In T484#9341053, @MSantos wrote:

Is this something the Language-Team should track?

@Nikerabbit is this something the Language-Team should track?

Sorry, this is still active, just stalled; aka on the parsing/CTT side we still definitely plan to move conversion tables into their own MCR slot and out of wikitext transclusion.

To get started, follow https://www.mediawiki.org/wiki/ResourceLoader/Foreign_resources.

No activity since 2021.

Sometimes the spaces can be the LCS, so they are highlighted as the context and all the words are shown as differences. See T326773: Wikidiff2 considers each space to be a separate word for my thoughts on this.

In T117279#9255216, @Sollyucko wrote:

I would like to have side by side available as an option on mobile, since inline diffs are sometimes an illegible mess of alternating words, e.g. an extreme case in https://en.m.wikipedia.org/wiki/Special:MobileDiff/1180439256: F38450324

Consider hiding or surfacing side by side diffs in mobile

Change 963393 merged by jenkins-bot:

[mediawiki/core@master] DifferenceEngine: Comments on diff page should be themeable

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

Change 963395 merged by jenkins-bot:

[mediawiki/core@master] DifferenceEngine: Make timestamps data readable

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

Change 963395 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] DifferenceEngine: Make timestamps data readable

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

Change 963393 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] DifferenceEngine: Comments on diff page should be themeable

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