Apologies for not sending out this announcement before hand.
Short summary: The machine that Phabricator is hosted on rebooted itself
last night due to high temperatures. It ended up just shutting itself
Today we needed our DataCenter Technician to reapply the thermal paste
in an attempt to remedy the issue. That took less than 10 minutes but it
happened during the middle of the day.
Full details: https://phabricator.wikimedia.org/T131742
And yes, we are requesting a backup machine so issues like this won't
have as much of an impact on you (our users):
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
There is clearly a need for a generic solution to hash fragment
routing in MediaWiki.
So far I've seen needs in MultimediaViewer, Kartographer,
MobileFrontend, Gather and potential needs in VisualEditor. There are
probably other bespoke solutions in other extensions too.
It would be great to take a minute and standardise on something (we
can always change it later).
I invite your discussion here:
and your thoughts on my straw man proposal:
We are planning to enable automatic redirect following in all REST API
 HTML entry points on April 25th. When responding to a request for
a redirected title , the response headers will contain:
For most clients, this means that their HTTP client will automatically
follow redirects, simplifying common use cases. The few clients with a
need to retrieve the redirect page content itself have two options:
1) Disable following redirects in the client. For HTML and
data-parsoid entry points, the response still includes the HTML body &
regular response headers like the ETag.
2) Send a `?redirect=false` query string parameter. This option is
recommended for browsers, which lack control over redirect behavior
for historical security reasons.
If you do have a need to avoid following redirects, you can make these
changes before the feature is enabled. Internally, we have already
done so for VisualEditor and the Mobile Content Service. See also
https://phabricator.wikimedia.org/T118548 for background & related
Let us know if you have any concerns or questions about this.
Gabriel Wicke for the Wikimedia Services Team
: https://en.wikipedia.org/api/rest_v1/?doc (using en.wikipedia.org
as an example)
What's the best way to build OOjs UI locally into the MW lib directory
I'm having two issues:
1. The README.md says:
"Install dev dependencies and build the distribution files:<br/>`$ npm
This does not actually build to dist for me.
I then tried:
npm run-script publish-build
That partly works but has many errors:
However, it apparently creates the key files.
2. I see update-oojs-ui.sh, but it looks like it's only intended for
when the OOjs UI change is already published.
I had to hack it up with:
npm install '/home/matthew/Code/Wikimedia/oojs/oojs-ui/'
which seems to basically work.
If there is not yet a proper way to do this, I'll probably add this as
This should be documented, probably at
tomorrow at 1800 UTC (10am PST) i would like to upgrade bast1001 and
schedule some downtime. I anticipate about an hour.
Data from home dirs has already been rsynced elsewhere (and is in Bacula).
Please switch to bast3001 or bast2001 during this period (or permanently if
they are closer for you anyways).
Daniel Zahn <dzahn(a)wikimedia.org>
In addition to the smaller bandwidth requirements for VP9 video encoding
versus Theora or VP8, Microsoft is adding support for VP9 video and Opus
audio in WebM to Windows 10 in the summer 2016 update.
Currently in Win10 preview builds this only works in Edge when using Media
Source Extensions, and VP9 is disabled by default if not
hardware-accelerated, but it's coming along. :)
If the final version lands with suitable config, users of Edge version 15
playback on Wikipedia. Neat!
Things still to do in TimedMediaHandler:
* add transcode output for audio-only files as Opus in WebM container
* keep working on the Kaltura->VideoJS front-end switch to make our lives
easier fixing the UI (Derk-Jan & Brion) and to prep for...
* eventually we'll want to use MPEG-DASH manifests and Media Source
Extensions to implement playback that's responsive to network and CPU speed
and can switch resolutions seamlessly. This may or may not be a
prerequisite for Win10 Edge playback if MS sticks with the MSE requirement.
* consider improving the transcode status overview at
Special:TimedMediaHandler; it reports errors in a way that doesn't scale
Things still to do in Wikimedia site config:
* add VP9/Opus transcodes to our config (audio, 240p, 360p, 480p, 720p,
1080p definitely; consider 1440p and 2160p for Ultra-HD videos)
* consider dropping some VP8 sizes (desktop browsers that support VP8
should all support VP9 now; old Android versions that don't grok VP9 might
be main target remaining for VP8)
Things to consider:
* VP9 is slower to encode than VP8, and a transition will require a lot of
back-running of existing files. We *will* need to assign more video
scalers, at least temporarily.
* I started writing a client-side bot to trigger new transcodes on old
files. Prefer I should finish that, or prep a server side script that
someone in ops will have to babysit?
* in future, the ogv.js JS decoder shim will still be used for Safari and
IE 11, but I may be able to shift it from Theora to VP9 after making more
fixes to the WebM demuxer. Decoding is slower per pixel but at a lower
resolution you often get higher quality because of better compression and
handling of motion -- and bandwidth usage is much better, which should make
it a win on iPhones. This means eventually we may be able to reduce or drop
the Ogg output. This will also tie in with MPEG-DASH adaptive streaming, so
should be able to pick best size for CPU speed more reliably than current
* longer term, AOMedia codec will arrive (initial code drop came out
recently, based on VP10) with definite support from Google, Mozilla, and
Microsoft. This should end up supplementing VP9 in a couple years, and
should be even more bandwidth-efficient for high resolutions.