Tomorrow at 8.30am PST / 4.30pm UTC there will be an expected downtime of
https://gitlab.wikimedia.org services for a few minutes.
A server is physically moving to a new rack. We expect maximum 10 minutes
but more likely just 5 minutes of downtime.
Nothing will change about the software or data itself. Just don't plan a
deployment during this time please. Thank you
--
Daniel Zahn <dzahn(a)wikimedia.org>
Site Reliability Engineer
Hi.
The definition of revision databases was published and also
demonstrated. It was demonstrated on file
"skwiki-20240101-pages-meta-history.xml.bz2". It might be interesting
for you. More: https://archive.org/details/revision-database
Dušan Kreheľ
We have changed the name of API Platform to MediaWiki Interfaces Team
<https://www.mediawiki.org/wiki/MediaWiki_Interfaces_Team> (MWI). Our aim
is to better align the branding of the team with the work we do and expand
the scope of the work we will do within MediaWiki Engineering
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>.
MediaWiki Interfaces aligns with our efforts to work on APIs (Action and
REST), Hooks, and some extensions - the systems that individuals and teams
use to interface with MediaWiki. We also support teams looking to build
features and fixes atop MediaWiki in coordination with our sibling teams,
MediaWiki Platform and Content Transform. Use the #mw-interfaces-team
*How do I reach your team on Phabricator?*
Use the #mw-interfaces-team
<https://phabricator.wikimedia.org/tag/mw-interfaces-team/> tag to get
items onto our radar. If you're unsure, use the #mediawiki-engineering tag
and we will look at it as a group and determine the best team to own the
issue.
What happens to the API Platform Phab tag?
We will keep the #api_platform phabricator tag
<https://phabricator.wikimedia.org/tag/api_platform/>, The type has changed
from “group” to “umbrella”. MWI will continue to monitor the board for the
next 2 quarters for incoming issues and triage them.
What happened to the MediaWiki-Interface Phab tag?
Since this tag is related to the UI of MediaWiki, we have renamed the tag
to #mediawiki-ui <https://phabricator.wikimedia.org/tag/mediawiki-ui/> to
be more in line with its purpose. The #mediawiki-interface tag will remain
as a way to redirect to the UI workboard.
--
Frantz Joseph
Sr. Engineering Manager | MediaWiki Engineering
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