Hello,
If you're not maintaining a mediawiki instance or don't work with
mediawiki's installer/updater, feel free to ignore this email (sorry for
spam).
The aforementioned RFC has reached phase 3, which means we need to reach
out to stakeholders and since this RFC is going to impact third party
installations, hence this email.
Currently and in theory, mediawiki supports upgrading from 1.2 (released in
2004) to its current version but if this RFC is approved, you wouldn't be
able to upgrade from versions older than two LTS releases. So for example
for upgrading to 1.35, you can't upgrade to it from 1.26 or lower, 1.26 was
released in end of 2015 and EOL'd in end of 2016, if you want to upgrade
from 1.26, you have to first upgrade to 1.34 and then you would be able to
upgrade to 1.35 [Note that this is an example, 1.35 is already released and
thus not affected by this RFC, this is going to affect future releases].
Here's the RFC: https://phabricator.wikimedia.org/T259771 Feel free to
chime in and spread the word to other stakeholders.
Thanks
--
Amir (he/him)
This is the weekly TechCom board review in preparation of our meeting on
Wednesday. If there are additional topics for TechCom to review, please let
us know by replying to this email. However, please keep discussion about
individual RFCs to the Phabricator tickets.
Activity since Monday 2020-09-28 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
-
T264334 <https://phabricator.wikimedia.org/T264334>: Could the
registered module manifest be removed from the client?
-
New task about the possibility of removing the huge module registry
from the js sent to the client. The idea is being discussed.
Committee board activity: Nothing to report, besides inbox
New RFCs: none.
Phase progression:
-
T262946 <https://phabricator.wikimedia.org/T262946>: Bump Firefox
version in basic support to 3.6 or newer
-
Moves to P3 (explore)
-
It is pointed out that we’ve dropped support in production for TLS
1.0/1.1 in january, so de facto only Firefox 27+ is able to
connect to the
wikimedia sites
-
In light of that, it’s suggested that we might bump the minimum
supported versions of browsers further.
IRC meeting request: none
Other RFC activity:
-
T260714 <https://phabricator.wikimedia.org/T260714>: Parsoid Extension
API.
-
Last call to be approved, that will end on October 7 (tomorrow)
-
T487 <https://phabricator.wikimedia.org/T487>: RfC: Associated
namespaces.
-
On last call to be declined, there is some opposition to the
opportunity of marking it as declined on phabricator. Last call
should end
on October 7 (tomorrow)
-
T263841 <https://phabricator.wikimedia.org/T263841>: RFC: Expand API
title generator to support other generated data.
-
Erik asks if this is going to be generally applied to all generators
or not.
Cheers,
Giuseppe
--
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation
Hello,
This email contains updates for October 7, 2020. For the HTML version, see:
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-10-07
Cheers,
Deb
------------------------
*= 2020-10-07 =*
== Callouts ==
* SRE: MediaWiki DC switchback to eqiad will be Tuesday, October 27.
Services switchback will be either the following day or the day before, TBD.
== Product ==
=== Structured Data ===
* Updates: "beta" milestone for mediasearch
== Technology ==
=== Site Reliability Engineering ===
* Updates:
** S5 replication broke on some hosts
https://phabricator.wikimedia.org/T263842, IR draft
https://wikitech.wikimedia.org/wiki/Incident_documentation/20200925-s5-repl…
** MediaWiki DC switchback to eqiad will be Tuesday, October 27. Services
switchback will be either the following day or the day before
** Service 2 Service communication now all encrypted
** Digicert unified cert renewal still in purchasing, we’re using
LetsEncrypt at all edges for now, with Globalsign also available as a
backup if necessary.
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
Hi,
I'm Ratnabali, I'm an Outreachy applicant. I went through the "Refactor
Selenium tests and perform cleanup" project description and found it to be
really interesting. I would like to work on the project and would
appreciate any help on how to get started with first-time contributions.
Best Regards,
Ratnabali Dutta.
Earlier today a vulnerability was uncovered that might have permitted
unauthorized users to manipulate project membership or create or delete
VMs within cloud-vps. That issue has since been resolved, and there is
currently no evidence that anyone exploited it.
Nevertheless, out of an abundance of caution: if you are a project
admin, please review the members and projectadmins of your project. If
you see any unknown or untrusted users or unexpected instances, remove
them and notify me directly about what you found and what you've done.
Thank you!
-Andrew + the WMCS team
[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