There's not much left, and what's there should arguably be moved off to Gerrit (or GitLab). There's a few things listed at https://www.mediawiki.org/wiki/Gerrit/GitHub. Anything not included can be added on a one-off basis, not worth the automation. I recently tried to fix the automation behind making that on-wiki list and it takes quite a lot of complexity to run and still has both false negatives and false positives because there are 1000s of repos under the org which all sorts of edge cases from different things we mirrored from Gerrit in different ways.

@CCiufo-WMF Sounds good to me. Note that this task is for dropping Modern support ("Grade A"). Basic support ("Grade C") is a next step and we'll make sure to wait with that until DST are ready for it. I see no rush on that one. That work is tracked under T288287, which is already marked as requiring the DST spike to complete first (T332716).

From a ResourceLoader perspective, I delegate largely to product teams to indicate readiness. I indentified stakeholders in this comment a few weeks ago:

Very nice!

@MoritzMuehlenhoff I believe this is something your team usually do, but not 100% sure. Feel free to re-route as needed!

Added to the task description:

As I understand it, this property is meant to expose headings that exist in the content. Similar to how e.g. edit section and other mechanisms work by section. It seems the tool in question is using this to find and validate a particular portion of the page. Both the API property and the tool in question are not documented or named in relation to a graphical interface for a table of contents. If we retroactively treat it as such, I expect a feature request will be filed to introduce support for exposing "section" information, in which case the property sections would seem like a natural fit, bringing us back to where we are.

The Wikibase code is using IDatabase::unionQueries(). It seems the Rdbms library currently doesn't offer any other way to run union queries.

Using http://ecomfe.github.io/est/fiddle/#version=2.4.0&autoprefix=false&est=false&autorun=false, it seems this was upstream less.js behaviour in 2.4.0 and changed to the current behaviour in 2.5.0, though seemingly without coverage by upstream's test specification, hence it was likely missed by less.php maintainers until now (noting that Wikimedia took over less.php maintenance in 2019).

Task description:

• Rescoped to not be never-ending but rather a specific major upgrade.
• Added a acceptance critera instead of "we did the task", which is undefined. Proposing to use the upstream test suite, like we do now.

From the task description:

[…] which is both good (no performance penalty) and bad (no 3d styling capability).

This regression was not intentional. As a workaround, use https://codesearch-old.wmcloud.org/. I'll try to get this working in a few weeks time, patches welcome meanwhile.

In T307064#8690255, @gerritbot wrote:

Change 894749 merged by jenkins-bot:

[mediawiki/core@master] Add renameUsersMatchingPattern.php

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

I've made the repos read-only and marked them as archived.

The GOVUK Frontend design system are also working on dropping IE11 support. Their work highlighted an issue that I think affects us as well. Upstream details at https://github.com/alphagov/govuk-frontend/issues/2718, summarised below.

@colewhite The above should fix 99% if not 100% of them. I'm leaving this open and assigned to you to remove the filter or confirm that it's not solved and then feel free to sign back over to me :)

@Tacsipacsi wrote at T332305: Error “View mediainfoview does not exist” on SDC pages

https://commons.wikimedia.org/wiki/File:Hochfeiler_in_Alps.jpg?debug=1

Error

View mediainfoview does not exist

@resources/wikibase/view/ViewFactory.js/SELF.prototype._getView

Impact:

• SDC still seems to work.
• The ImageAnnotator gadget doesn’t work on the same page, but this is probably unrelated, as the error appears on other pages as well, where ImageAnnotator does work.

This appears to work correctly on 1.39 and later, at least with the changes of T325529 applied.

In T71622#5530874, @DannyS712 wrote:

The Special namespace should support subpages, so that, eg, https://en.wikipedia.org/wiki/Special:Version/License has a breadcrumb link to https://en.wikipedia.org/wiki/Special:Version

I don't recall if the omission was intentional by @tstarling and @Ladsgroup. It do think it stands out as suspicious so if the transition to the Builder pattern can serve as a carrot to improve code to not do this, I think that's worthwhile a few temporary exemptions. It depends on whether they'd be temporary.

In T332101#8696333, @RoySmith wrote:

We have (at least on enwiki) [[Category:Orphaned articles]], which does get crawled. For example, [[Abdulkareem Mohammad Jamiu]] is a recent orphan, and Google has already found it. So it seems to me there's no need for a sitemap.

I'm less familiar with projects outside of enwiki, so I can't speak for how this works on those.

I'd lean toward using current jwt (i.e. no pinning), and using or making a version of oauth2 that works with it - if feasible.

I suggest preserving a redirect. The page is publicly linked from 50% of production pageview traffic (i.e. most mobile artcles), contains actual navigable information (i.e. not empty, or personalised to current viewer), and isn't noindex'ed or otherwise rell=canonical'ised to a different URL.

From https://wikitech.wikimedia.org/wiki/Incident_documentation/20140113-Poolcounter:

We had a partial "outage" of […] causing at least the Main Page not to be displayed, and anon users getting PoolCounter error messages instead.

[There] were no signs that the poolcounter daemons weren't working correctly.

The poolcounter.log on fluorine was being spammed with lots of "Queue full" messages.

Ditto. Let's close for now.

I don't know the intervals of mwcli. Fresh is distributed as a set of standalone bash scripts. If it uses those and/or if it runs the underlying docker commands directly, then that should be fairly straight forward indeed.

In T331138#8688891, @Joe wrote:

not cleaning up stale thumbnails and we're still serving them to the public not a production error? Can you suggest a better tag then?

The new bare metal host has 280GB disk space on /srv. We currently use 134GB (52%) of this broken down as follows:

https://gerrit.wikimedia.org/g/operations/alerts/+/84ebd79671756c33ac0f75ed5625f59c5d8cc582/team-perf/webperf.yaml#80

Not sure when I can get around to this. Lowering priority to reflect reality and clear from dayjob "Need Triage".