[crosspost from Maps-l]
Today the Wikimedia Foundation is announcing the deprecation of the public
API for Wikimedia map tiles. Around mid October the Foundation will end
support for the Wikimedia Maps Service API [1]. This change affects people
using Wikimedia maps on their own website or app. Maps on the Wikimedia
sites, in Wikimedia-hosted tools and gadgets, and on maps.wikimedia.org
won't be affected.
This decision was made based on recent outage incidents, primarily due to
spikes in third party usage, along with an analysis showing that more than
a third of maps provided are to non-Wikimedia services (including many to
for-profit organizations).
After the most recent incident [2], the service was limited so that only
cached maps tiles would be available. While this protected the servers, it
made the service unpredictable and highlighted the unsustainability of our
tile service. So, we have made the decision to discontinue the maps APIs
for non-Wikimedia users.
This change will allow our teams working on Maps to focus on the
sustainability of the maps used within Wikimedia projects.
You can follow the implementation of this change on Phabricator [3].
Best,
Erica Litrenta
[1] https://maps.wikimedia.org/osm-intl/
[2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20200204-maps
[3] https://phabricator.wikimedia.org/T261424
--
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)
Hello everyone,
today, I looked to a handful of unit and integration tests in MediaWIki
core, and I noticed we do not have a single namespace pattern for tests.
I would find it natural for integration tests (that are already in the
integration subfolder) to be in MediaWiki\Tests\Integration namespace, and
unit tests to be in MediaWiki\Tests\Unit.
This would allow those two kind of test to use "same" class name, and would
avoid hacks similar to
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631818/13/tests/phpunit/u…
.
However, I'm not sure if this pattern I described in previous paragraphs is
the best one, and what is the best way of going forward in this case.
Thanks for any comments,
Martin
Hi,
This is an informational message for users of MediaWiki-Docker.
We just merged a change[0] to Mediawiki-Docker's working directory. This
change was made in order to support rest.php[1]. It also makes use of a new
docker image that fixes issues with loading pages with slashes in
VisualEditor[2].
As a result of this change, your existing LocalSettings.php file may point
to the wrong database directory. Although there is a script that should
update it automatically for you[3], you can take a look at the
DEVELOPERS.md troubleshooting section in core if you happen to run into an
issue connecting to your database.
[0] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/626144
[1] https://phabricator.wikimedia.org/T261051
[2] https://phabricator.wikimedia.org/T262392
[3]
https://gerrit.wikimedia.org/r/plugins/gitiles/releng/dev-images/+/refs/hea…
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation
This week's deployment branch of MediaWiki encountered multiple issues
during deployments, first on Wednesday and again on Thursday, ultimately
ending in rolling back to wmf.10 each time[1]. Further, Thursday's
deployment resulted in a security incident which is currently still under
investigation[2].
Due to the ongoing investigation, deployments of wmf.11 are blocked until
further notice.
You can find more information in Phabricator and I will update this mailing
list when the status changes.
Sincerely,
The humble train conductor.
1. T263177 1.36.0-wmf.11 deployment blockers
<https://phabricator.wikimedia.org/T263177>
2. T264370 User authentication security issue (Oct 1)
<https://phabricator.wikimedia.org/T264370>
Everyone on all Wikimedia wikis has been logged out, and will have to log
back in again.
This was done out of an abundance of caution, after we received one (1)
user report of being logged in as someone else.
Said report coincided with the deployment of a new MediaWiki release which
caused other problems around User session objects; this is possibly related
and under active investigation.
We believe the number of possibly-affected users was small, and that the
time window in which the error was possible was short. However, we believe
that resetting all sessions is a prudent measure to ensure that the impact
is limited.
More details to follow, after technical investigation has determined a
cause. https://phabricator.wikimedia.org/T264370
Apologies for the disruption,
--
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2020-09): 328
Active Maniphest users (any activity) in (2020-09): 1052
Task authors in (2020-09): 558
Users who have closed tasks in (2020-09): 306
Projects which had at least one task moved from one column to another on
their workboard in (2020-09): 333
Tasks created in (2020-09): 2544
Tasks closed in (2020-09): 2415
Open and stalled tasks in total: 45655
* Only open tasks in total: 44681
* Only stalled tasks in total: 974
Median age in days of open tasks by priority:
Unbreak now: 0
Needs Triage: 591
High: 896
Normal: 1296
Low: 1861
Lowest: 1895
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2020-09): 3
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Thu 01 Oct 2020 12:00:17 AM UTC)