I would like to nominate Siddharth for CR+2 (the right to approve and merge
changes in MediaWiki core and extensions). He has done excellent work in
core and various extensions, most notably Gadgets and the related core
infrastructure.
Please voice support or concerns on
https://phabricator.wikimedia.org/T360442
Hello friends,
In code review, it was suggested I get wider consensus for my proposed
changes, so I would like to invite your feedback on the following Extension
SyntaxHighlight_GeSHi ticket:
https://phabricator.wikimedia.org/T361407
Summary: I propose adding parser tags <sh> for <syntaxhighlight>, and <shi>
for <syntaxhighlight inline>. Reason: These are much shorter to type.
Thank you for your consideration.
Sincerely,
Novem Linguae
Hi all,
On Thursday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.39.7
- 1.40.3
- 1.41.1
This will resolve two security issues in MediaWiki core, along with bug
fixes included for maintenance reasons. This includes various patches for
PHP 8.0, 8.1, 8.2 and 8.3 support.
This release may or may not be made with a CVE number formally attached,
due to the recent delays in receiving them from MITRE.
We will make the fixes available in the respective release branches and
master in git. Tarballs will be available for the above mentioned point
releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow later.
As a reminder, MediaWiki 1.35 became end of life (EOL) in December 2023.
It is strongly recommended to upgrade to either 1.39 (the next LTS after
1.35), which will be supported until November 2025, 1.40, which will be
supported until June 2024, or 1.41, which will be supported until December
2024.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hey everyone,
Product and technology development at the Wikimedia Foundation is guided by
the annual plan, which sets the focus for the Foundation – what are the
central areas we are trying to address?
We have now posted the Product & Technology draft key results for next
fiscal year on Meta. They aim to explain what outcomes we are working
towards:
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…
The objectives and draft key results are divided into different sections,
and the ones most relevant to this list are "WE5" and "WE6" (Wiki
Experiences #5 and #6). They are about evolving the MediaWiki platform to
better meet Wikipedia's core needs and to give technical staff and
volunteer developers the tools they need to effectively support the
Wikimedia projects.
To give a couple of examples, here we have key results like
"By Q2, introduce a sustainability scoring system for the Toolforge
platform across a variety of technical and social factors. By Q4, improve
one of its key technical factors by 50%"
or
"Identify by Q2 and complete by Q4 one or more interventions to evolve the
MediaWiki ecosystem’s programming interfaces to empower decoupled, simpler
and more sustainable feature development"
Out of context, they might not say much, but there are more explanations on
the Meta page. We welcome any feedback on the draft:
https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2024-…
(The Wikimedia Foundation fiscal year runs from July through June, so this
covers July 2024 through June 2025.)
Best,
*Johan Jönsson*Manager, Product Ambassadors
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
I will be *upgrading Gerrit* from the 3.7 series to the 3.8 series. I
have scheduled the upgrade for *Monday March 25th at 9am UTC*. It is
immediately after the UTC morning backport & config window.
The upgrade requires the Gerrit service to be stopped for the duration
of the upgrade. Given we do not need to reindex all the changes, the
downtime should be just a few minutes.
Gerrit 3.8 brings:
* Rebase on behalf of the uploader, so that the rebaser does not take
over the change (the original uploader is preserved)
* Rebase a chain of changes: when working with a series of change, the
whole series can be rebased atomically which saves a lot of manual
rebasing actions
* Browser Notifications: get a notification when a change requires
your attention
* And more UI changes
<https://www.gerritcodereview.com/3.8.html#gerrit-ui-changes>
The release notes: https://www.gerritcodereview.com/3.8.html
<https://www.gerritcodereview.com/3.8.html>The upgrade task:
https://phabricator.wikimedia.org/T354886
Deployment calendar entry
<https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240325T0900>
Antoine "hashar" Musso
Wikimedia Release Engineering
Hi,
*TL;DR;*
We have started our journey of deprecating the ObjectCache
<https://doc.wikimedia.org/mediawiki-core/master/php/classObjectCache.html>
class and moving to ObjectCacheFactory
<https://doc.wikimedia.org/mediawiki-core/master/php/classObjectCacheFactory…>
: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/955771. This means we
have stopped using the *$instances* member in ObjectCache. If you are an
extension author or maintainer, please look at the new interface in
ObjectCacheFactory and migrate callers (if you find any).
*Longer version*
Recently, there has been some on-going work on ObjectCache and we realized
code was taking a factory based pattern due to various code paths to
configure, setup and obtain BagOStuff cache instances. With this patch:
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/955771, we created a
proper MediaWiki factory service and deprecated various methods on the
ObjectCache class including the static member `ObjectCache::$instances`
which used to hold references to various instances of the caches
(BagOStuff) - sounds familiar? Yes, we're getting rid of scattered usage of
global state one class at a time :).
We have taken care of places [1][2][3] where this public member was
referenced, so, we are certain there are no consumers of this field
<https://codesearch.wmcloud.org/deployed/?q=ObjectCache%3A%3A%5C%24instances>
both
in MW core and extensions that we deploy today in production, and we
encourage extension authors and maintainers to migrate to the new way of
constructing and/or obtaining cache instances via ObjectCacheFactory which
goes through our global services container (with DI capabilities).
You can also have a look at the Phabricator task [4] which explains the
problem that this refactoring solves/improves and the impact it has on
MediaWiki. The patch will ride the train next week (starting March 25th,
2024) and if there are any issues found along the way, please file a task
and add #MediaWiki-lib-BagOStuff.
This work is only step 1 into unifying, centralizing and getting rid of
global state in the logic related to the ObjectCache class and making it
consistent with how we do things with the global services locator today in
MediaWiki.
External/related links, see:
* https://www.mediawiki.org/wiki/Manual:$wgObjectCaches
* https://www.mediawiki.org/wiki/Object_cache
Thank you!
P.S: I personally want to thank Daniel Kinzler and Timo Tijhof for all the
code review and guidance into making this work materialize and about to hit
production. <3
[1] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1011159
[2]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmEdit/+/1009498
[3]
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DonationInterface/+/1…
[4] https://phabricator.wikimedia.org/T358346
--
Derick,
On behalf of MediaWiki Platform Team
Please, take a look of https://phabricator.wikimedia.org/T360357 I know 19
days is very close to request this, but in this country (Argentina) is very
difficult to schedule it with more time. Thanks in advance!!