- Beta Cluster
- Test wikis
- test2wiki
- testwiki
- testwikidata
- testcommonswiki
- Group 0
- Group 1
- Group 2
Description
Details
Event Timeline
@Johan: Tagged for User-notice. This isn’t due to go in soon but there’s no objection to announcing it’s happening and then when it’s done.
Or we can just announce as it’s about to happen?
Text for TechNews would be something like "The video player will change to be simpler and more modern. The current beta feature will become the experience for everyone. The old player will be removed."
I think it's easier to just let people who want to test it test it as a beta feature, on their normal wiki where they speak the language and so on. Unless there's a difference in experience I'm missing?
Change 591124 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] [testwiki] Force videojs-only mode for TimedMediaHandler
Change 591124 merged by jenkins-bot:
[operations/mediawiki-config@master] [testwiki] Force videojs-only mode for TimedMediaHandler
Mentioned in SAL (#wikimedia-operations) [2020-04-20T18:38:30Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T248418 [testwiki] Force videojs-only mode for TimedMediaHandler (duration: 01m 01s)
Change 612347 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Make videojs the only player on all group0
Change 612348 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Make videojs the only player on all group1
Change 612349 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Make videojs the only player everywhere
Change 612350 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Drop Beta Feature, no longer usable
Change 612351 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Don't read wmgTmhWebPlayer
Change 612352 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[operations/mediawiki-config@master] TimedMediaHandler: Drop pre-switch config, no longer read
Change 612347 merged by jenkins-bot:
[operations/mediawiki-config@master] TimedMediaHandler: Make videojs the only player on all group0
Mentioned in SAL (#wikimedia-operations) [2020-07-16T19:14:00Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: T248418 TimedMediaHandler: Make videojs the only player on all group0 (duration: 00m 57s)
Sorry, I noticed this probably a bit too late. I think T245377: Video.js player doesn’t work with Score should be a blocker to the default deployment—Video.js currently makes the score playback feature completely unusable, while it works just fine with Kaltura.
Given that much of Score is currently disabled with no fix in sight, I'm not sure that's a reasonable blocker.
As far as I know, Score is not disabled in its entirety, only processing of new scores is. Playback of existing scores is still possible. I’m really disappointed how WMF works on destroying as much functionality as possible (first making Graph unusable for non-JS users, now completely getting rid of Score…).
@Tacsipacsi: See https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette where and how to bring up constructive criticism instead of incorrect statements like "completely getting rid of Score". Thanks a lot! :)
I might actually prefer to delay until the remember-subtitles-setting fix is merged. I'm honestly not sure what the situation with Score is at this point, but if playback is broken that might be good to fix as well.
Blockers, I think:
- T258578: In the "New video player" beta feature, Subtitle and Quality lists are forced to LTR direction
- T258644: VideoJS audio player start button is misleading
- T258570: Increase interface's base font size for VideoJS player
- T258622: Poor display of media on Special:NewFiles
- T249204: New video player does not leave enough space in gallery
- T258638: Improving the accessibility of buttons that launch the player
- T138768: TMH video.js-mode 'info' button needs localizable alt and hover text
- T249249: Loading indicator renders in the top left corner instead of centre
And what will happen after the deployment with T246035: Videojs player for audio opens a dialog, which is unexpected?
It's a deliberate change, so I'm not sure what's actionable unless it's "make some kind of visual change to the placeholder". I really wish we had a multimedia team and some kind of project manager and a designer's time.
These three look more like matters of personal opinion than bugs. While it would be good to have them decided one way or the other, I don't think they should stall the rollout.
Localization issues should indeed be blockers. The rest are bugs that I could live with.
I am not sure that T258622: Poor display of media on Special:NewFiles is personal opinion :)
I honestly don't know how you want to deploy it in group 1. One more accessibility task, I forgot about it: T225640: Video.js mode doesn't show subtitles by default on non-English sites.
I am not sure that T258622: Poor display of media on Special:NewFiles is personal opinion :)
Regardless of whether its an opinion or not, it's purely a cosmetic issue. I don't think that should block deployment, personally.
This is a serious bug that breaks the UX and UI (look at audio buttons). Such bugs will always block deployment :)
The UX still works fine for me, including for audio files. I guess we'll have to agree to disagree.
@Iniquity: If you run into specific bugs, then please file specific bug reports with clear steps to reproduce (URLs, web browser and version and operating system, etc) as specific bug reports are off-topic here (this task is about deploying a piece of software instead). Thanks.
Thanks for the reminder, but if you had read a little above, you would have understood what we are talking about :)
@Iniquity: Ah, indeed I missed that this was already reported as T258622 (thanks). However part of what I tried to express still stands: Please add comments in dedicated bug reports. T258622 currently has no info if the impact of T258622 is a visual issue only, or if partially overlapping buttons also means that buttons become entirely unclickable (functionality issue). Please add relevant info to dedicated bug reports instead of this deployment ticket. Thanks a lot!