So after several changes in puppetmaster of mailman in the cloud, it works now: https://polymorphic.lists.wmcloud.org/hyperkitty/hyperkitty/list/test4@polymorphic.lists.wmcloud.org/2021/4/

Seconding what Martin said. Renaming a wiki is extremely complex and we have done it only once (b-x-old to be-tarask and that one is not also finished properly yet) and it's still quite a mess (probably the renaming script is also terribly broken by now) and all renames are blocked T172035: Blockers for Wikimedia wiki domain renaming (while some of the blockers are not applicable here, like wikidata support). It's also risky given that it can bring down all wikis.

From the other tickets, it looks like legal-related stuff is the reason why we're moving away from OTRS branding. To which decree do we need to get rid of "otrs"? For instance, I'm wondering whether the internal wiki ID can stay "otrs_wikiwiki" (note that changing that will likely be really really complex).

Hi, if you can wait for two to three weeks, we will get mailman3 up and running soon and you can enjoy a much more modern system (see https://lists-next.wikimedia.org). This is by no means blocking the request and you can go ahead with the old system if you want to.

No, that's enough. I just an email asking people to vote. Thanks.

[Fri Apr 16 15:25:54.109507 2021] [proxy_http:debug] [pid 12009:tid 140593783097088] mod_proxy_http.c(1920): [client 172.16.4.88:59876] AH01113: HTTP: declining URL uwsgi://localhost/hyperkitty/api/mailman/urls

:|

exim fully works.

https://gerrit.wikimedia.org/r/680328 is needed. https://gerrit.wikimedia.org/r/680335 is not (I disabled TLS for now there).

wow. Thanks!!!!

@Tchanders @Esanders Hi, is it okay if we revert that patch?

https://packagist.org/packages/wmde/hamcrest-html-matchers#v1.0.0

+1 to that. We do have our own apt, our own docker registry, and some more. We certainly can have our own npm registry as well (which I think is possible, correct me if I'm wrong), OT: I like to do the same for pypi so we stop shipping wheel binaries to production as well. But it would bring the whole discussion around processes and how to vet and push packages to our registry and I assume it should be determined beforehand.

The whole thing is a bit offtopic here but I want to say that I chose the installer logo like that as I have seen in another places that installer shows an incomplete logo to convey "it's being built for you" and it got even pointed out by other people that was a good choice. At end of the day, logos are subjective and you might like something someone else doesn't. We can have a semi-official voting for the installer logo somewhere if you insist.

There was one thing I missed in my comment on autolader and Joe pointed out in IRC that I did the test on mwdebug (where you can do xhgui) and mwdebug is a VM with different opcache (probably cold most of the time) with production. So the situation in production is better. Of course, we might need to improve things but that's another topic not related to this issue. Sorry my bad.

I created https://wikitech.wikimedia.org/wiki/Wikitech_logo, @SerDIDG Can you upload them in commons and add them to the page? I'll do the similar jazz with did with mw logo but faster (only one round, two week voting period and no legal clearance) to finish it.

lots of mw-deprecate cases are actually edge case scripts iterating over window object and thus emitting a deprecation warning for every variable. It adds up really quickly.

Requests the bot made are not that bad but probably had a terrible regression in wmf.1 (action=purge format=json forcelinkupdate= pageids=33330972 in API ):
https://performance.wikimedia.org/xhgui/run/view?id=60780f591e29d3593756eaae

It's in this lexeme https://www.wikidata.org/w/index.php?title=Lexeme:L456103&action=history

You can reproduce it with https://www.wikidata.org/w/index.php?oldid=1394890460

Basically ran this command on mwmaint1002:

mwscript extensions/Wikibase/repo/maintenance/changePropertyDataType.php wikidatawiki --property-id P8671 --new-data-type external-id

This is an easy task. Similar work in the past: T269205: Change P920 property’s data type from string to external identifier

oh my bad, we do catch db errors in DataUpdateAdapter, I thought it's a core class. Making a patch now.

Oh this is another case of catching DBErrors.
See https://www.mediawiki.org/wiki/Database_transactions#Use_of_transaction_rollback (emphasis not mine)

Callers might catch DBError exceptions without either re-throwing them or throwing their own version of the error. Doing so is extremely bad practice and can cause all sorts of problems from partial commits to simply spewing up DBTransactionError errors. Only catch DB errors in order to do some cleanup before re-throwing an error or if the database in question is used exclusively by the code catching errors.

It's a bit hard to test it but reverting https://gerrit.wikimedia.org/r/c/oojs/ui/+/668488 would fix the issue. I'm sure this is an upstream problem

This is very likely caused by changed in ooui (there are a lot of them touching position of input element recently in TagMultiselectWidget) (T276483: TagMultiselectWidget always puts input on separate line after line 1 for example)

Thanks. Greatly appreciated <3

Thanks. This reduces a lot of deprecation warnings in enwiki.

To make it even more fun, in RTL languages it's left-aligned

Yes. Please don't add more herald rules (T108586: Herald rules causing delays to task edit saves - getting worse). You can use maintenance bot instead. Here are some examples https://github.com/Ladsgroup/Phabricator-maintenance-bot/blob/master/project_grouper.py#L7

That's why we need to automate things even more. This doesn't happen with CX or analytics as their patches are made automatically. That's for later though.

So the derivatives and misc cases don't build a MECE list and possibly will drag on for years to come. Given that the site logo and software logo has changed and all current misc cases are either done or have a ticket on the relevant team's radar. I'm inclined to call this resolved. Any objection to that?

If I have to choose between removing Turkish or adding Czech, I would go with the former. Having a bad pattern doesn't mean we can add more bad patterns on top. These are binary png files that are not easily changeable (unlike svg).

I've done this a while ago.

this is done while ago

It depends on the compataibility policy of the extension I assume. For example, if master of your extension is only compatible with master (most cases). It's safe to drop pre 1.27 as the update.php wouldn't work at all but if it's an edge case (I think language bundle is different, also wikibase) then it depends on the what versions it's compatible with.

Isn't this done not done properly? T271983: Add altwiki to RESTBase

The alter table would be:

ALTER TABLE /*_*/interwiki
  MODIFY iw_url BLOB NOT NULL;

In T277116#6992885, @Marostegui wrote:

Come up with the alter table statement

Thanks. We will likely bother you in two or three weeks. Most of the work is done.

That's according to the designs (T275542: (MS 6) using the tooltip component in the QB)

https://github.com/wmde/wikit/pull/411

So it's not that bad, it's cleared in the store. Just not rerendered. I'm looking for ways to trigger it.

looked at it, it's a bit all over the place but doable. Before making a patch I think we need to find a good style. I disagree with text-decoration-style: double as it's barely distinguishable from the rest (specially keep accessibility in mind please). Color coding might not be that bad, but it'll conflict with flagged revs probably.

Ugh. Two of them were fixed in meta, three were not. We need to wait another week for the next round of deployment.

Yes. Please clear your browser cache.

In T23272#6989695, @Xaosflux wrote:

@Ladsgroup would you mind commenting on this, especially as to how developer-costly it would be to implement?

So not even deleteBatch.php batches the deletions. It basically doesn't exist in mediawiki. What should happen here is that Nuke should queue deletion jobs instead.

The traceback doesn't involve abusefilter but it's still possible. I'm also worried it might be flagged revs (in some weird combo config) but fawiki is really similar to enwiki so I think it's not that.

This is borderline UBN.

https://polymorphic.lists.wmcloud.org/mailman3/postorius/lists/ ^^

What is needed to move this out of Refine column?

What is needed to move this out of Refine column?

Yes. I'm aware of that but I rather do it at end of the all the work to reduce the risk of issues.

Found the problem. This fixes it. If gets merged by Monday, I'll backport it. Sorry for the inconvenience. This codebase is beyond rotten. Any change on it is bound to break something it seems but it's necessary to make the code slightly more maintainable.

Yeah. I was worried this might happen. Basically we dropped the quality tier but there are edits that are marked as quality and the system doesn't know what to do with them. My suggestion would be to mark all of them as checked in the database. That's not hard to do but I rather not do it in a weekend (where our capacity is reduced and if things go wrong, can't ask for help)

Yes. It should be fixed now.

I'll try to see what can be done to fix it.