Page MenuHomePhabricator

1.36.0-wmf.2 deployment blockers
Closed, ResolvedPublicRelease


Backup Train Conductor
Release Version
Release Date
Jul 27 2020, 12:00 AM

2020 week 31 1.36-wmf.2 Changes wmf/1.36.0-wmf.2

This MediaWiki Train Deployment is scheduled for the week of Monday, July 27th:

Monday July 27thTuesday, July 28thWednesday, July 29thThursday, July 30thFriday
Backports only.Branch wmf.2 and deploy to Group 0 Wikis.Deploy wmf.2 to Group 1 Wikis.Deploy wmf.2 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.2 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.1
Next: 1.36.0-wmf.3

Event Timeline

brennen moved this task from Backlog to Next on the User-brennen board.
brennen added a subscriber: brennen.

Automatic branch cut went OK. Ran the pre-deployment-window steps (scap prep, applied security patches if there were any, deployed to testwikis).

Unblocked, because T259023: PHP Notice: Undefined index: content-disposition doesn't seem to be bad enough to be a blocker. Also, hopefully has a fix now, waiting for review.

brennen added a subscriber: LarsWirzenius.

Keeping one eye on it, but now unblocked and seems as calm as should be expected for group0. Will re-assign to Lars at end-of-local-workday.

We've reached today's North America cutoff for deploys. Assuming a resolution on T259126, train can resume in Lars' local morning.

The fix for T259126 is backported to wmf/1.36.0-wmf.2 and the train should be good to move forward in the (EU) morning.

Promoted back to group1, out of train window. Wanted to do this early so that if everything seems OK for a few hours, we (me or Brennen) can promote to group2 optimistic-opportunistically. If that fails, we roll back to group1 and try again on Monday if any problems found have been fixed.

This deployment's sound track was Queen's "We will rock you".

Rolled out with fix for T258609 at 21:52 UTC, noticed T259311 and rolled back to group1 by 22:12. Calling it for the week, sending train status mail.

It's the end of my working day Eastern Time Thursday. From the above, I'm assuming it's safe to wrap up my day and I'll get T259311 fixed tomorrow (Friday) and do the parsoid-packaging dance required so that you can bump parsoid to v0.13.0-a3 on Monday for wmf.2 and try again. cc @Arlolra, @Sbailey.

Let me know if that timeframe needs to be accelerated.

(For clarity: No need to accelerate.)

It looks like the train was rolled without the fix for T259311, which got deployed to master but not cherry-picked to wmf.2 before the train was rolled. Cherry-pick is at . This is probably not super-high-importance, given that wmf.3 is at our doorstep and it also has this fix in it. We'll make sure wmf.3 has a fix for T257504 as well.

Seeing several T259536 a minute. I don't know the impact there, but it's a fatal. Loathe as I am to roll back the train on a Monday, it feels like something that should probably be rolled back.

brennen moved this task from Doing to Done or Declined on the User-brennen board.