Page MenuHomePhabricator

1.36.0-wmf.21 deployment blockers
Closed, ResolvedPublicRelease


Backup Train Conductor
Release Version
Release Date
Dec 7 2020, 12:00 AM

2020 week 50 1.36-wmf.21 Changes wmf/1.36.0-wmf.21

This MediaWiki Train Deployment is scheduled for the week of Monday, December 7th:

Monday December 7thTuesday, December 8thWednesday, December 9thThursday, December 10thFriday
Backports only.Branch wmf.21 and deploy to Group 0 Wikis.Deploy wmf.21 to Group 1 Wikis.Deploy wmf.21 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.21 should be added as subtasks beneath this one.
  • Any open subtask(s) block the train from moving forward. This means no further deployments until the blockers are resolved.
  • If something is serious enough to warrant a rollback then you should bring it to the attention of deployers on the #wikimedia-operations IRC channel.
  • If you have a risky change in this week's train add a comment to this task using the Risky patch template
  • For more info about deployment blockers, see Holding the train.

Related Links

Other Deployments

Previous: 1.36.0-wmf.20
Next: 1.36.0-wmf.22

Event Timeline

Heads-up that there's a new extension on the release branch tool, IP Info. Not plugged into anything in config, nothing special, shouldn't be an issue, but please shout at me / @Tchanders if it breaks something. :-)

I have rolled 1.36.0-wmf.20 on all wikis over the last hour. There was an issue with ParserOutput serialization but that has been rolled back from the code both in the wmf branch and the master branch, so 1.36.0-wmf.21 should be fine. The plan is to wait for the parser cache entries to dry out before switching entirely to json serialization.

Change 646887 had a related patch set uploaded (by DannyS712; owner: trainbranchbot):
[mediawiki/core@wmf/1.36.0-wmf.21] Branch commit for wmf/1.36.0-wmf.21

Change 646887 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.21] Branch commit for wmf/1.36.0-wmf.21 - is fixing T269727, which is pretty bad. It will only affect group0 cause we only have old revision caching enabled there, but I would recommend we back port it still.

Mentioned in SAL (#wikimedia-operations) [2020-12-09T20:18:10Z] <twentyafterfour> wmf.21 looks good on group1 wikis. Still seeing T269603 but not at an increased rate. (refs T264801)

Not sure if it’s serious enough to be a train blocker but this seems to be a visual regression in wmf.21: T269801

Mentioned in SAL (#wikimedia-operations) [2020-12-10T22:32:31Z] <twentyafterfour@deploy1001> Synchronized php-1.36.0-wmf.21/resources/lib/ooui/oojs-ui-widgets-wikimediaui.css: sync to fix T269477 and unblock T264801 (duration: 01m 04s)

Hi @DannyS712 ! Thanks for finding that CentralNotice bug. We've got a patch ready for it, but I wouldn't consider it a train blocker. It's a sanitization failure, but one that doesn't expose us to any harm outside of those error log entries - the parameter is used in a query which is properly performed using DB wrapper functions. We'd prefer to put the fix out with some other accumulated CN patches after the year-end fundraiser.

We'd prefer to put the fix out with some other accumulated CN patches after the year-end fundraiser.

Just adding to @Ejegg's comment... AFIK, at this time, that API is rarely used, if at all, and there were just 16 of these errors on production in the last month (logstash).