can someone to update list https://phabricator.wikimedia.org/P10500 which
contains repositories which haven't mediawiki/mediawiki-codesniffer.
I found in list that much repositories are empty, and repositories which
aren't available on Gerrit.
So, can someone please update this list of repositories (in
mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at
least, contains one PHP file. or to provide me command with which I can
update list when I want, so I don't need to request it every time.
P. S.: Happy weekend! :)
I want to notify you that I have, on behalf of the WikiTeq company, made a
task https://phabricator.wikimedia.org/T298277 for requesting repository
ownership for the Lingo extension.
In case that you have any kind of questions, please let me know. :)
For the last 2 quarters, the Search Platform team has been working on
upgrading our Elasticsearch clusters to version 7.10.2 . Keeping our
software up to date is part of the usual project hygiene, allowing us to
benefit from bugs and security fixes, performance improvements, and new
features. In our case, upgrading to Elasticsearch 7.10.2 is also a required
step towards a potential move to OpenSearch .
After much testing, fixes and validations, we are now ready to start the
final migration process. We are anticipating a 3-week migration process,
starting on August 29 2022. You can follow along on Phabricator .
What does this mean for you?
For users of Special:Search, Special:MediaSearch and other user-facing
Search interfaces, the upgrade should be fully seamless, and should not
cause any disruptions to normal usage.
For users of Cloudelastic  who are accessing the Elasticsearch API
directly, there might be minor API changes that could affect your queries.
Please review the documented breaking changes . Most of the breaking
changes are not related to queries, so it is unlikely that any client code
will break with this upgrade.
If you have any questions about this process, you can find us in
#wikimedia-search on IRC, or at discovery(a)lists.wikimedia.org. Have fun!
The Search Platform team
*Guillaume Lederrey* (he/him)
Wikimedia Foundation <https://wikimediafoundation.org/>
This is a quick note to highlight that in six weeks' time, the REL1_39
branch will be created for MediaWiki core and each of the extensions and
skins in Wikimedia git, with some (the 'tarball') included as sub-modules
of MediaWiki itself. This is the first step in the release process for
MediaWiki 1.39, which should be out in November 2022, approximately
six months after MediaWiki 1.38.
The branches will reflect the code as of the last 'alpha' branch for the
release, 1.39.0-wmf.28, which will be deployed to Wikimedia wikis in the
week beginning 12 September 2022 for MediaWiki itself and those extensions
and skins available there.
After that point, patches that land in the main development branch of
MediaWiki and its bundled extensions and skins will be slated for the
MediaWiki 1.40 release unless specifically backported.
If you are working on a new feature that you wish to land for the release,
you now have a few days to finish your work and land it in the development
branch; feature changes should not be backported except in an urgent case.
If your work might not be complete in time, and yet should block release
for everyone else, please file a task against the `mw-1.39-release` project
If you have tickets that are already tagged for `mw-1.39-release`, please
finish them, untag them, or reach out to get them resolved in the next few
We hope to issue the first release candidate, 1.39.0-rc.0, two weeks after
the branch point, and if all goes well, to release MediaWiki 1.39.0 a few
weeks after that.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
The performance team are progressively deploying the MediaWiki
multi-DC project. This project allows us to make use of servers in the
Dallas data center which were previously idle. When the project is
fully deployed, most MediaWiki backend GET requests will be routed to
whichever data center is nearest to the CDN node at which the request
* Stage 1: test.wikipedia.org and test2.wikipedia.org. Already done.
* Stage 2: mediawiki.org. Planned for deployment on August 15.
* Stage 3: traffic percentage. A small percentage of all requests
will be sent to the nearest DC. Date undecided, but could be as
early as August 22.
* Stage 4: full deployment. Date TBA. But it will be soon. If you
need to update your tools, please start updating.
For more details, see T279664 <https://phabricator.wikimedia.org/T279664>.
I'm not aware of any blockers. As far as I know, we could fully deploy
it now and it would more or less work. If you think otherwise, please
let us know.
-- Tim Starling
With the risk of being off-topic, I want to express my gratitude to
all the members of the Wikimedia tech community for being such a
supportive and helpful group! Not only here, but on all communication
It's been years since one of my questions (most of which could be
classified as obscure) has gone unanswered. Also, I recently had to go
through all my emails since June and I noticed that except for a few
announcements and obvious spam, all other other threads had at least
one answer. For me, this is the sign of a great community to be in.
Thanks again and keep up the good work!
This is announcement of a breaking change without deprecation, per the Stable
Interface Policy <https://www.mediawiki.org/wiki/Stable_interface_policy>.
If you have any objections, concerns or questions, please respond to this email
as soon as possible.
*What will change?* We are adding two methods to the DBPrimaryPos interface
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/828058>. Any classes
implementing that interface will break if they do not implement these methods.
Other usage of the class, such as calling methods, is unaffected. The change
will be part of the 1.39 release.
*Why is the change needed? *We need a plain data representation of the
DBPrimaryPos objects, so they can be stored in a cache without relying on native
PHP serialization of objects. Native PHP serialization should be avoided because
it is brittle and insecure
Issues may arise particularly when the class in question changes or PHP itself
is updated. The problem that prompted this change is T316601
*Why is deprecation not feasible? *There is no backwards compatible way in PHP
to add methods to an interface, nor is there a way to warn classes that are
lacking the new methods. For this reason, it is generally recommended to provide
a base class rather than expecting extensions to implement an interface
directly. In this case however, there is no base class, and the interface is
marked as /stable to implement./ But there appear to be no classes in extensions
that implement the interface in question, so it seems reasonable to just add the
Principal Software Engineer, Platform Engineering