Page MenuHomePhabricator

1.36.0-wmf.10 deployment blockers
Open, MediumPublicRelease

Details

Release Version
1.36.0-wmf.10
Release Date
Mon, Sep 21, 12:00 AM
Backup Conductor
mmodell

2020 week 39 1.36-wmf.10 Changes wmf/1.36.0-wmf.10

This MediaWiki Train Deployment is scheduled for the week of Monday, September 21st:

Monday September 21stTuesday, September 22ndWednesday, September 23rdThursday, September 24thFriday
Backports only.Branch wmf.10 and deploy to Group 0 Wikis.Deploy wmf.10 to Group 1 Wikis.Deploy wmf.10 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.10 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.
  • For more info about deployment blockers, see Holding the train.

Related Links

Other Deployments

Previous: 1.36.0-wmf.9
Next: 1.36.0-wmf.11

Event Timeline

mmodell created this task.Jul 14 2020, 8:19 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 14 2020, 8:19 PM
thcipriani triaged this task as Medium priority.
thcipriani updated Backup Conductor, added: dancy.
hashar added a subscriber: hashar.Tue, Sep 8, 7:14 PM
brennen moved this task from Backlog to Next on the User-brennen board.Wed, Sep 9, 7:16 PM
thcipriani reassigned this task from brennen to dancy.Thu, Sep 17, 7:15 PM
thcipriani updated Backup Conductor, added: mmodell; removed: dancy.
thcipriani added a subscriber: brennen.

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

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

Change 628979 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.10] Branch commit for wmf/1.36.0-wmf.10

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

Hi @DannyS712. @thcipriani instructed me to remove the non-blocking tasks from the subtasks list. An empty subtasks lists is the indication that there are no outstanding train blockers. Hope that helps!

Hi @DannyS712. @thcipriani instructed me to remove the non-blocking tasks from the subtasks list. An empty subtasks lists is the indication that there are no outstanding train blockers. Hope that helps!

Normally if the tasks are resolved / can be closed they are left associated with the blocker task, eg last week (T257977: 1.36.0-wmf.9 deployment blockers)

Hi @DannyS712. @thcipriani instructed me to remove the non-blocking tasks from the subtasks list. An empty subtasks lists is the indication that there are no outstanding train blockers. Hope that helps!

I don't think we've ever had a solid policy and is mostly up to the train conductors discretion -- if the whole problem is resolved, we usually close the task, but leave it attached to the train. If there's any reason to leave the ticket open (incomplete fix, revert for unblocking train, fix in master is different for fix in train, etc), then we usually remove the subtask.

It's a useful heuristic to say that a train with open subtasks can't roll forward.

Hi @DannyS712. @thcipriani instructed me to remove the non-blocking tasks from the subtasks list. An empty subtasks lists is the indication that there are no outstanding train blockers. Hope that helps!

I don't think we've ever had a solid policy and is mostly up to the train conductors discretion -- if the whole problem is resolved, we usually close the task, but leave it attached to the train. If there's any reason to leave the ticket open (incomplete fix, revert for unblocking train, fix in master is different for fix in train, etc), then we usually remove the subtask.

It's a useful heuristic to say that a train with open subtasks can't roll forward.

Okay, good to know. I was just wondering

FYI: I filled T263749, but not sure if it is caused by wmf.10.