Page MenuHomePhabricator

1.35.0-wmf.37 deployment blockers
Closed, ResolvedPublicRelease


Backup Train Conductor
Release Version
Release Date
Jun 15 2020, 12:00 AM

2020 week 25 1.35-wmf.37 Changes wmf/1.35.0-wmf.37

This MediaWiki Train Deployment is scheduled for the week of Monday, June 15th:

Monday June 15thTuesday, June 16thWednesday, June 17thThursday, June 18thFriday
Backports only.Branch wmf.37 and deploy to Group 0 Wikis.Deploy wmf.37 to Group 1 Wikis.Deploy wmf.37 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.37 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.35.0-wmf.36
Next: 1.35.0-wmf.38

Related Objects

Event Timeline

brennen moved this task from Backlog to Next on the User-brennen board.
brennen subscribed.

Patches going out with the train: - T254960: Hard deprecate Revision::getComment, T251853: Hard deprecate Revision::getPage - T254964: Hard deprecate Revision::getSize - T254966: Hard deprecate Revision::getTimestamp

As noted on the tasks, there are a number of methods with the same names; while I'm fairly sure all uses of the four Revision methods have been removed from deployed code, I may have missed some.
Potential impact: logspam with deprecation notices, but no failures (no breaking changes made)
If this occurs: will send patches to fix the callers, core patch shouldn't need to be reverted

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

@DannyS712 I've added you to the list of users able to access Beta Cluster in WMCS, which means you can access logstash-beta (read about how, and WMCS SSH). There is not much traffic in Beta, but it should make it easier to check ahead of time if any production code in a production-like configuration is triggering deprecation warnings.

Change 605718 merged by Lars Wirzenius:
[mediawiki/core@wmf/1.35.0-wmf.37] Branch commit for wmf/1.35.0-wmf.37

Branch cut happened automatically. Merged the change in Gerrit manually (V+1 and CR+2). Set up branch on deployment host. Applied security patches. Cleaned up old branch (.34, .35). Deployed to testwikis. Verified version number changed testwiki. This all happened in a bit over an hour this time, which is a lot faster than last time. I started early to avoid overrunning over the EU SWAT window this time.

Now ready to wait for train window in a few hours.

Group0 promoted to this week's version.

Note that Logstash-beta is down, which means there has been less visibility in the state of this branch. QA have been active, but we're not aware of any of the backend errors or deprecations those may have triggered.

T254801: Logstash-Beta cannot be accessed: 504 Gateway Time-out

brennen added a subscriber: LarsWirzenius.

Group1 is currently on .37. Will watch logs and reassign ticket to Lars at local end-of-day.

Current status: The train is rolled back to group0. As we're approaching the 3pm Pacific deploy cutoff with 2 open blockers (albeit T255614 looks like it's got a fix), I'm calling it stalled here for the day. Train can resume in Lars's morning, pending fixes for both issues.

Note for the deployment of the fix for T255608: DBUnexpectedError when moving a page with a StructuredDiscussion talkpage:
There are two patches, and the core patch ( should be deployed before the flow patch (, otherwise there may be a bunch of logspam from the deprecated hook being used

Promoted group1 just now, outside a normal deployment window, to have more time on group1 before we do an expedited promotion to group2 later today. (Or try to.) was mentioned by @RhinosF1 as having a patch in case the problem shows up in production, not only beta cluster. was mentioned by @RhinosF1 as having a patch in case the problem shows up in production, not only beta cluster.

The patch to roll out to production is so as long as that is fixed before it's deployed, it should be fine.

The fact it fatals when VE isn't enabled is intended, The editing team can't have thought about anywhere having VE off in wmf wikis.

Currently on all wikis, but we're keeping an eye on T255704 and will roll back to group0 if another spike occurs.

Taking this task again. So far, logstash looks fairly calm in the last 12 hours.

Things still haven't blown up, I'm declaring train done for this week.