This is different from GraphQL which is a web service (rather than an extension)
Fri, Feb 15
Also, I think it's totally fine if we build & host the same "base" release images as well. In my mind there's nothing wrong with that, but I think we should use the same Dockerfiles in order to reduce the maintenance overhead. If someone wants to use the ones built and hosted on Docker's infrastructure, great! If someone doesn't trust that and wants to use the ones built and hosted on our infrastructure, also great!
The docker image found here: https://hub.docker.com/_/mediawiki
uses these Dockerfiles: https://github.com/wikimedia/mediawiki-docker
and is built on Docker's infrastructure using this configuration: https://github.com/docker-library/official-images/blob/master/library/mediawiki
@Smalyshev again, it's impossible to justify (or not justify) a platform, because (afaik) there is no product strategy for MediaWiki. There's no "business case" to support a platform
Thu, Feb 14
If it's going to be deployed in this sprint, it can stay in this ticket, if it's in another sprint, new tickets! :)
@Tchanders are you working on this?
Wed, Feb 13
That's great news! :)
Tue, Feb 12
Mon, Feb 11
Move towards implementing Wikibase/Wikidata UI as a Single Page Application (SPA) - written in TypeScript to mitigate the downsides of using an otherwise untyped language
Sat, Feb 9
Fri, Feb 8
or even better might be to link to the block list... it looks kinda gross right now, but it at least lists the currently active blocks:
Can we link to the block log like this?
Thu, Feb 7
I'm skipping QA on this since you have to have to be a global Staff to access the tool.
Hmm... I actually don't think there is a way to test this since the problem is theoretical.
Wed, Feb 6
As for myself, I think T208175: Proposal: Blocks should exist as serialized pages is perhaps a better solution to the same problem, so I for one think this should be declined in favor of that, but as it doesn't look like I'll be working on either, I leave that up to TechCom
Tue, Feb 5
Yep. This all sounds good to me.
Fri, Feb 1
Thu, Jan 31
Wed, Jan 30
Thu, Jan 24
Put on the schedule to SWAT https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190124T1900
I created a new issue to hopefully prevent this in the future: T214546: Title::loadFromRow() should return a new instance of Title
Wed, Jan 23
@Anomie ok, my only other question is... where is this being cached that it's being loaded again?
@Anomie Also, even if this is being loaded at that point, I'm not seeing where it would be statically cached?