Can you port the Vector patch to 1.35.0-wmf.32 ? https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/Vector/+/596516/

The cherry pick conflicts since the wmf branches does not have Refactor: Simplify and standardize menu definitions e048c2a729a2fc513a967b689bf6a219b6a56428

Do we also need to backport the mediawiki/core patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/596522/ BaseTemplate: language_urls property should always reflect true emptiness ?

I can but given it doesn't swat cleanly my preference would be to let this ride the train then to deploy an untested bespoke patch? The languages box does display - it just doesn't display on pages without any languages. I agree that's not ideal, but it can be worked around and feels like something that we could leave broken until Wednesday/Thursday.

The core change is not needed - that deals with the bigger issue that led to this bug.

Note that there’s no train this week (releng offsite, apparently), so this would remain unfixed until next Wednesday/Thursday.

What Lucas Said, the fix would only land next week May 27/28.

So I guess we can backport the Vector patch and swat it for the wikis that are currently using 1.35.0-wmf.32 (group1 right now). And when the rest of wikis are promoted next Monday they will have the fix as well.

That's fine with me. I'm not sure if this effects content translation or wikidata but I defer to product teams around this decision. I can write a patch but the new patch will not be tested anywhere so applying it seems a little risky for me so I wouldn't want to do that unless this was deemed urgent.

I can't judge the risk but I'd say from the product side it's pretty bad and I'd rather not leave it broken for another week.

Isn't this still a train blocker, per Lydia?

I talked to @ovasileva earlier today and my understand is she felt it was not a train blocker per a conversation with @Pginer-WMF . She said she'd reach out to Lydia.

The risk here from a development perspective is that such a fix will be bespoke for this particular branch. Note: rolling back is not an option due to caching implications.

FWIW if we do need to patch this we're likely looking at a patch Wednesday PM earliest but most likely sometime Thursday. For me to feel comfortable with this, it will involve:

1. 1-2hrs writing a new patch specifically for this branch
2. getting that patch code reviewed
3. getting it staged on a labs wiki for QA (as this patch will have been untested in a production like setting)
4. QA
5. SWAT.

The question is whether this issue is serious enough to commit to all that right now given the limited availability schedules of teams.

It seems this affects:

• No Wikidata link to add interlanguage links
• No Content Translation grey links to start a translation
• No UniversalLanguageSelector cog for easy access to language settings.

Discussed with @Lydia_Pintscher @Pginer-WMF and we decided that, given the risks, it would be okay to wait until next week's train, so long as we don't see this affecting articles that already have language links.

ContentTranslation and UniversalLanguageSelector are affected as well.

I am aiming at pushing 1.35.0-wmf.32 on the remaining wiki on Monday 25th during European afternoon. We will thus have those features hidden/disabled until the next version reaches all wikis on Thursday May 28th. Is that ok for everyone?

In T252800#6152293, @hashar wrote:

ContentTranslation and UniversalLanguageSelector are affected as well.

I am aiming at pushing 1.35.0-wmf.32 on the remaining wiki on Monday 25th during European afternoon. We will thus have those features hidden/disabled until the next version reaches all wikis on Thursday May 28th. Is that ok for everyone?

Sounds good to me.

Looks like this is getting worse. Multiple reports from users today on ukwiki who can no longer add articles, while it work for them as late as yesterday.

Yes, this was broken by the wmf.32 release which reached Wikipedias a few hours ago (and all other wikis a week ago); the next release, wmf.34, is being branched now, and should fix that for all, but won't be on Wikipedias for another 50 hours.

@Jdforrester-WMF can I use this opportunity to learn the deployment process better? Do I understand correctly that the patches associated with the current task were supposed to be deployed in the Mediawiki train - American Version window (19-21 UTC today) in which 1.35.0-wmf.34 would be deployed? Given that we are at 21:03 UTC right now and the change is still not seen on Wikipedias, I checked Special:Version on Wikipedias and they are still on MW 1.35.0-wmf.32; is it safe to assume that the issue is that wmf.34 has blockers (i.e. T253022 is still open)? And finally, if that is correct, would it be fair to say that the next time we can expect the patches for this task to go live would be June 2nd?

In T252800#6174604, @Huji wrote:

@Jdforrester-WMF can I use this opportunity to learn the deployment process better?

Of course.

Do I understand correctly that the patches associated with the current task were supposed to be deployed in the Mediawiki train - American Version window (19-21 UTC today) in which 1.35.0-wmf.34 would be deployed?

Yes.

Given that we are at 21:03 UTC right now and the change is still not seen on Wikipedias, I checked Special:Version on Wikipedias and they are still on MW 1.35.0-wmf.32; is it safe to assume that the issue is that wmf.34 has blockers (i.e. T253022 is still open)?

Yes, that's indicated on the given task. Working on it now.

And finally, if that is correct, would it be fair to say that the next time we can expect the patches for this task to go live would be June 2nd?

No. Should be within the hour, assuming we find all the bugs and get it out.

In T252800#6174656, @Jdforrester-WMF wrote:

In T252800#6174604, @Huji wrote:

And finally, if that is correct, would it be fair to say that the next time we can expect the patches for this task to go live would be June 2nd?

No. Should be within the hour, assuming we find all the bugs and get it out.

But if we were unsuccessful in resolving the blockers, then the whole train would be pushed back by one week, correct? (Or do we use an earlier SWAT window in such circumstances?)

In T252800#6175054, @Huji wrote:

In T252800#6174656, @Jdforrester-WMF wrote:

In T252800#6174604, @Huji wrote:

And finally, if that is correct, would it be fair to say that the next time we can expect the patches for this task to go live would be June 2nd?

No. Should be within the hour, assuming we find all the bugs and get it out.

But if we were unsuccessful in resolving the blockers, then the whole train would be pushed back by one week, correct? (Or do we use an earlier SWAT window in such circumstances?)

Not a whole week; it'd be pushed to the next deployment day, which in this case would have been Monday 1 June.

Change 596522 abandoned by Jdlrobson:
BaseTemplate: language_urls property should always reflect true emptiness

Reason:
Okay, I'm going to move this decision into the skins themselves. It seems like the path of least resistance right now.

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