|mediawiki/core||wmf/1.36.0-wmf.10||+966 -3||Branch commit for wmf/1.36.0-wmf.10|
- Backup Conductor
- Release Version
- Release Date
- Sep 21 2020, 12:00 AM
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 21st||Tuesday, September 22nd||Wednesday, September 23rd||Thursday, September 24th||Friday|
|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|
- See https://wikitech.wikimedia.org/wiki/Deployments for full schedule.
How this works
- Any serious bugs affecting wmf.10 should be added as subtasks beneath this one.
- Use this form to create 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.
|Resolved||Release||dancy||T257978 1.36.0-wmf.10 deployment blockers|
|Resolved||Urbanecm||T263750 abuse filter matching global_user_groups doesn't work any more|
- Mentioned In
- T256171: Unescaped message used in HTML within LogEventsList (CVE-2020-25815)
- Mentioned Here
- T263749: Deletion of a file at Commons fails: Wikimedia\Rdbms\DBTransactionError from line 1519 of /srv/mediawiki/php-1.36.0-wmf.10/includes/libs/rdbms/database/Database.php: Explicit transaction still active. A caller may have caught an error. Open transactions: FileDeleteForm::doDelete
T257977: 1.36.0-wmf.9 deployment blockers
T263014: Argument 2 passed to File::userCan() must be an instance of User, null given, called in /srv/mediawiki/php-1.36.0-wmf.9/includes/filerepo/LocalRepo.php on line 275
T263601: ApiQueryGlobalUsage.php Undefined index error when accessing $pageIds
T263675: Undefined class constant 'LIMIT'
@dancy can I ask why you removed the blocker subtasks instead of resolving them? If T263014: Argument 2 passed to File::userCan() must be an instance of User, null given, called in /srv/mediawiki/php-1.36.0-wmf.9/includes/filerepo/LocalRepo.php on line 275, T263675: Undefined class constant 'LIMIT', and T263601: ApiQueryGlobalUsage.php Undefined index error when accessing $pageIds are no longer blocking the train, they can be closed, but should stay associated with this ticket
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.