Hello,
I will be *upgrading Gerrit* from the 3.5 series (which is end of life)
to the 3.6 series. I have scheduled the upgrade for *Thursday January
11st at 9am UTC*. It is immediately after the UTC morning backport &
config window.
The upgrade will require the Gerrit service to be stopped for the
duration of the upgrade. I do not anticipate any issue and the service
should be back up in half an hour.
Gerrit 3.6 introduces Submit Requirements
<https://gerrit-documentation.storage.googleapis.com/Documentation/3.6.0/con…>
which would let us tune what is required for a change to be merged by
Gerrit. I do not plan to make any change to the default rule, but the
requirements (such as a change having Code-Review +2 and Verified +1)
would show up in the GUI which will make it easier to understand what is
missing.
There are lot of other smaller changes in the upstream release notes:
https://www.gerritcodereview.com/3.6.html
The upgrade task: https://phabricator.wikimedia.org/T309870
Deployment calendar entry
<https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240111T0900>.
Antoine "hashar" Musso
Wikimedia Release Engineering
Hello,
I will be *upgrading Gerrit* from the 3.6 series (Upgraded on Jan 11) to
the 3.7 series. I have scheduled the upgrade for *Monday January 22nd at
9am UTC*. It is immediately after the UTC morning backport & config window.
The upgrade will require the Gerrit service to be stopped for the
duration of the upgrade. This upgrade requires a full reindexing of the
nearly million of changes accross the couple thousands of repositories,
and if I remember well that step alone takes ~ 40 minutes.
Gerrit 3.7 brings:
* Full markdown support in comments (3.6 already added support for
|`backticks`| )
* Mention of users via |@<user>| which is disabled by default but we
might enable
* Bulk actions from the change list to add reviewer, topics or hashtags
* Auto switch between light and dark theme based on OS preference
* And more UI changes
<https://www.gerritcodereview.com/3.7.html#gerrit-ui-changes>
The release notes: https://www.gerritcodereview.com/3.7.html
<https://www.gerritcodereview.com/3.7.html>
The upgrade task: https://phabricator.wikimedia.org/T354885
<https://phabricator.wikimedia.org/T354885>
Deployment calendar entry
<https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240122T0900>
Antoine "hashar" Musso
Wikimedia Release Engineering
Hello,
In the list=tag API query module, the tag source type named "extension" is
being renamed to "software" [1]. As of MediaWiki 1.42, "extension" still
appears alongside "software" in the tag source lists but is deprecated [2].
In future versions of MediaWiki, the "extension" entries will no longer
appear.
The use of "extension" is misleading since it does not exclusively refer to
tags defined by MediaWiki extensions (via the onListDefinedTags hook), but
also those defined in MediaWiki core (via
ChangeTagsStore::DEFINED_SOFTWARE_TAGS). The distinction isn't really
useful to clients anyway.
[1] https://phabricator.wikimedia.org/T247552
[2]
https://en.wikipedia.org/w/api.php?action=query&list=tags&tgprop=source&tgl…
Hi,
I'm happy to share that the next Web Perf Hero award (for 2023 Q4) goes to
TK-999, in recognition of their contributions, which made a huge positive
impact on the performance of Wikimedia software.
TK-999 worked on improving MediaWiki’s autoloading mechanism <
https://gerrit.wikimedia.org/r/c/853972> (
https://phabricator.wikimedia.org/T274041) specifically for classes which
have been namespaced, by including them in the classmap. This means our
autoloader will not spend significant amounts of time searching for files
in directories, but rather just do a direct lookup. This approach is
particularly optimized for speed and as a result, Wikipedia’s backend
response time gained a 20% increase in the portion of requests that
complete within 50ms.
This award is given once a quarter, and manifests as a Phabricator badge.
More information and past recipients:
https://wikitech.wikimedia.org/wiki/Web_Perf_Hero_award
Phabricator badge: https://phabricator.wikimedia.org/badges/view/17/
-- Derick Alangi, on behalf of the MediaWiki Platform Team
Hello everyone,
The Design Systems Team is pleased to announce that ResourceLoader now
supports basic code splitting for Codex
<https://www.mediawiki.org/wiki/Codex> components. The way this works is
similar to how Codex icons already work: you list the components you need
in your ResourceLoader module definition, and only the components you need
will be bundled. This should be helpful for performance, reducing the
amount of code that is loaded by loading only the components your feature
needs, not the entire library. Most new and existing uses of Codex should
be able to use this feature. If you maintain code that uses Codex, we
recommend trying this out!
There's documentation for how to use this feature on the Codex page on
mediawiki.org
<https://www.mediawiki.org/wiki/Codex#Requiring_Codex_components_in_MediaWik…>,
and you can also look at the CodexExample extension
<https://gitlab.wikimedia.org/repos/design-systems/CodexExample> for a more
complete example of how to use this feature. If you have any questions, or
run into any issues trying to use this feature, we're here to help, feel
free to reply to this email or post on the Codex talk page on mediawiki.org
<https://www.mediawiki.org/wiki/Talk:Codex>.
So far we have only implemented the most basic iteration of code splitting.
We plan on building some more advanced features to help with deduplication
of components as well. For more details about our plans, see the epic task
<https://phabricator.wikimedia.org/T349423> on Phabricator.
Roan Kattouw
Software engineer on the Design Systems Team at the Wikimedia Foundation
Hi all,
We'll be upgrading[0] phabricator.wikimedia.org this coming Saturday,
starting at noon PST. This involves re-imaging a machine, so some
downtime is expected, although we'll do our best to keep it at a minimum.
As usual, operations will be conducted on libera.chat's
#wikimedia-operations.
[0]. https://phabricator.wikimedia.org/T334519
--
Brennen Bearnes
Release Engineering
Wikimedia Foundation
As some of you may know, the Wikimedia portal pages (https://github.com/wikimedia/wikimedia-portals) are virtually unmaintained, rely on unmaintained external tools, and use old-school coding styles (like concatenating JavaScript files). I feel like we'd better give it a complete overhaul (https://phabricator.wikimedia.org/T311361).
In my humble opinion, the best toolkit replacement I can think of is using Vue and Vite, with some kind of static site generation (SSG) tools. Vue and Vite are both used by Codex, and allow us to write code like we are in 2024.
What do you think of this? Any input is welcome.
Sincerely,
Diskdance
Whenever I access the API, I get "Wikimedia Error: Our servers are currently under maintenance or experiencing a technical problem." Sometimes if I wait a bit, I'll get a few good requests, but it will shortly go back to the previous message. My code was working just fine a few days ago and I didn't change anything.
Sent with [Proton Mail](https://proton.me/) secure email.
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, January 10, 2024
Time: 16:00-17:00 UTC / 08:00 PST / 11:00 EST / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>