Hello,
The wikis are still on 1.36.0-wmf.10 as we are still working on a user
authentication issue from last week that prevented us from rolling
1.36.0-wmf.11 [T264370].
We are effectively cancelling this week deployment of 1.36.0-wmf.12. We
start rolling 1.36.0-wmf.11 on Tuesday and reasses from there.
The change scheduled for 1.36.0-wmf.12 would thus be deployed as part of
the next train: 1.36.0-wmf.13.
Recap:
1.36.0-wmf.10, fully deployed Thursday, Sep 24th
1.36.0-wmf.11, rolled back Thursday, Oct 1st
1.36.0-wmf.12, scheduled this week and canceled hereby
We aim at deploying wmf.11 on Tuesday October 13rd and wmf.13 in the
days that follow.
[T264370] User authentication security issue (Oct 1)
https://phabricator.wikimedia.org/T264370
--
Antoine "hashar" Musso & cie
Release Engineering
Dear all,
We’re really happy to announce the second edition of the Coolest Tool Award
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award>!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and enhance the experience for Wikimedia communities.
There are incredible many great tools out there. It’s time to celebrate
this & to make the great work volunteer developers do more visible to
everyone :-)
The Coolest Tool Award ceremony will take place virtually this year, given
the current circumstances around events and travel. We will provide more
details soon about the specific logistics and dates.
The award is organized & selected by the *Coolest Tool Academy 2020*
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award#Coolest_Tool_Award_2020>.
We plan to recognize the greatest tools in a variety of categories, for
examples you can look at last year’s categories
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award/2019>.
As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!
Please use this form:
https://docs.google.com/forms/d/e/1FAIpQLSf5ZmXXamn9sRsagEiiZcUZDn1Ga0sF3Xm…
to recommend tools *by October 14, 2020*. You can nominate as many tools as
you want by filling out the form multiple times.
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2020_Survey_Privac…
Thank you very much for your ideas & recommendation(s)!
We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!
Thanks :-)
Joaquin, for the Coolest Tool Academy 2020
--
Joaquin Oltra Hernandez
Developer Advocate - Wikimedia Foundation
Hello,
It has been a while since I gave an update on the state of abstracting
schema and schema changes in mediawiki
<https://phabricator.wikimedia.org/T191231>. So here's a really long one.
So far around half of the mediawiki core tables have been migrated to
abstract schema (plus lots of extensions lika Wikibase, Babel, Linter,
BetaFeatures, etc.). Special thanks to Tgr for reviewing most of the
patches and Sam Reed and James Forrester for doing the extensions.
With the growing number of schemas being abstracted, this is going to
affect your development if you work on schema and schema changes in core or
any of the extensions. So If you do, please read Manual:Schema changes
<https://www.mediawiki.org/wiki/Manual:Schema_changes> in mediawiki.org
You might think that abstraction is just migrating SQL to JSON but it's
much more, we are making the database schema of mediawiki much more
consistent, We are basically addressing several long standing issues like
T164898 <https://phabricator.wikimedia.org/T164898> and T42626
<https://phabricator.wikimedia.org/T42626> as well.
*Improvement aspects*
First aspect is drifts between different DBMSes. Sqlite schema is being
produced by regex replacement (this code
<https://github.com/wikimedia/mediawiki/blob/c477bcf2c5c482d3189ec3579c5dee4…>)
which is less than great but at least it comes from one place. For
Postgres, its schema and MySQL/Sqlite has drifted so drastically, that
fixing it so far required 76 schema changes fixing issues ranging from
missing indexes to missing PKs, extra AUTO_INCREMENT where it shouldn't be,
missing DEFAULT values, drifting data types and much more. You can follow
the fixes of Postgres in here <https://phabricator.wikimedia.org/T164898>.
The second aspect is the inconsistency in the schema itself. How do we
model strings? VARCHAR? VARBINARY()? VARCHAR() BINARY? (all three are
different things). You'd be surprised how inconsistent our MySQL is. So
far, we are migrating all VARCHAR() BINARY fields to VARBINARY() (so far
ten schema changes).
Another inconsistency is timestamps. In MySQL, around half of them are
BINARY(14) and the other half VARBINARY(14) (but in Postgres all are
TIMESTAMPTZ), there is even a ticket
<https://phabricator.wikimedia.org/T42626> about it. It makes sense to
migrate all of them to BINARY(14) but not all timestamps are 14 characters,
e.g. expiry fields accept "infinity" as value and it's a valid timestamp in
Postgres ¯\_(ツ)_/¯ When you turn an expiry field to BINARY(14), "infinity"
becomes " infinity" and as the result mediawiki doesn't recognize it
as infinity ("infinity" != " infinity"). There are several ways to
move forward handling expiry fields, you can follow the discussion in this
gerrit patch <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631936>.
Another fun aspect: Booleans. MySQL doesn't have boolean, it translates
them to TINYINT(1) but other DBMSes don't have TINYINT, they have SMALLINT
and BOOL though (and we mostly use SMALLINT for them), we decided to go
with SMALLINT for these cases (which is different than what Doctrine DBAL
does, it uses BOOL, so we introduced our own custom type for booleans).
Last but not least: ENUMs. MySQL and Postgres support that but Sqlite
doesn't. Doctrine DBAL doesn't support ENUM at all (as it's an
anti-pattern) while core has eight fields that are ENUM. There's an RFC to
discourage using it in general. Feel free to comment on it.
<https://phabricator.wikimedia.org/T119173>
A miscellaneous note: The directories that hold the archive of sql patches
of schema change are exploding (some of the sql patches are even orphan but
we can't find them because there are so many of them). So I started a RFC
to clean that mess up: Drop support for database upgrade older than two LTS
releases <https://phabricator.wikimedia.org/T259771>
*What's next?*
- We continue to migrate more tables, hopefully we will get two third
of them by the end of the year (fingers crossed). You can follow the
progress in its ticket <https://phabricator.wikimedia.org/T230428>.
- We will support abstract schema changes, really soon, like in a
couple of weeks. Basically you start a json file containing snapshots of
before and after of a table and then a maintenance script will produce the
needed sql patches for you for different schemas. This will increase the
developer productivity drastically, since 1- Schema change sql files become
more reliable and consistent and less prone to errors like adding the
column to the wrong table in some DBMSes
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/328377/22/maintenance/mss…>
2- You don't need to know Postgres or Sqlite peculiarities to make patches
against it. The reason you need to proved the whole table for adding like
an index is that sqlite doesn't support all types of ALTER TABLES, you have
to create temporary tables, move the data around and then rename and drop
in some cases, producing beautiful sql patches like this
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/630341/1/maintenance/sqli…>
- We work on improving the script that reports drifts between core and
our production. I have already made it work with abstract schemas as well,
I will continue working on it to report even smaller differences like field
size, type, etc. Which is now much easier thanks to the abstract schema.
Slowly we will migrate that script to production (as part of SRE scripts)
and we will do automated reports and automated drift fixes (on small
wikis). You can follow the work on this ticket.
<https://phabricator.wikimedia.org/T104459> So far, this script is being
run manually but found more than thousand and thousands of drifts across
the cluster and all are fixed thanks to our amazing DBAs (look at the
ticket)
*How can I help?*
Glad you asked! You can follow the abstract-schema
<https://gerrit.wikimedia.org/r/q/hashtag:%22abstract-schema%22+(status:open…>
hashtag in gerrit and review patches or you can make them yourself (get
yourself familiar using the documentations
<https://www.mediawiki.org/wiki/Manual:Schema_changes>). If you maintain an
extension feel free to migrate its table(s) (and track it in this ticket
<https://phabricator.wikimedia.org/T259374>). If you use Postgres for
mediawiki, please help us with testing the improvements for Postgres.
Thanks for reading this long email!
Best
--
Amir (he/him)
I'm hoping to gather a bit of information on the current use of
MediaWiki-Vagrant by folks in the Wikimedia movement. I have started a
slowvote poll in Phabricator at
<https://phabricator.wikimedia.org/V24> that asks one question: "Do
you personally use MediaWiki-Vagrant to develop or test software for
the benefit of the Wikimedia movement?"
I would really appreciate folks taking a couple minutes to click
through to the poll and selecting one of the possible responses:
* Yes, I use it daily
* Yes, I use it occasionally
* No, I used to use it but have switched to another dev environment
* No, I tried it but it never worked well
* No, I have never used it
Data collected in the poll will be used to help me and others decide
if it is worth putting in additional work to revitalize the group
maintaining and improving MediaWiki-Vagrant.
Bryan
--
Bryan Davis Technical Engagement Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
Hi Everyone,
We’re happy to announce the October 2020 edition of the Technical Community
Newsletter
<https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2020/October>
is now available. The newsletter is compiled by the Wikimedia Developer
Advocacy Team. It aims to share highlights, news, and information of
interest from and about the Wikimedia technical community.
Check it out, and learn about what technical contributors have been up to
this past quarter, upcoming conferences & calls for papers, and how to get
involved.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything perfectly. We welcome your ideas for future
newsletters. Let us know what you would like to see or highlights you would
like us to include.
Subscribe to the Technical Community Newsletter
<https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>,
if you'd like to keep up with essential updates and information
Kindly,
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Hi everyone,
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search, Wikidata Query Service, Wikimedia
Commons Query Service, etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, October 7th, 2020
Time: 15:00-16:00 GMT / 08:00-09:00 PDT / 11:00-12:00 EDT / 17:00-18:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#
Hope to talk to you in a week!
—Trey
Trey Jones
Sr. Computational Linguist, Search Platform
Wikimedia Foundation
UTC-4 / EDT
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