Hello all!
For the last 2 quarters, the Search Platform team has been working on
upgrading our Elasticsearch clusters to version 7.10.2 [1]. 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 [2].
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 [3].
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 [4] who are accessing the Elasticsearch API
directly, there might be minor API changes that could affect your queries.
Please review the documented breaking changes [5]. 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
[1] https://phabricator.wikimedia.org/T263142
[2] https://phabricator.wikimedia.org/T280482
[3] https://phabricator.wikimedia.org/T308676
[4]
https://wikitech.wikimedia.org/wiki/Help:CirrusSearch_elasticsearch_replicas
[5]
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/breaking-chang…
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello everyone,
Wikimedia is participating in the winter edition of this year's Outreachy <
https://www.outreachy.org/> [1] (December 2022–March 2023)! The deadline to
submit projects on the Outreachy website is September 30th, 2022. We are
currently working on a list of interesting project ideas. If you have some
ideas for coding or non-coding (design, documentation, translation,
outreach, research) projects, share them here: <
https://phabricator.wikimedia.org/T313361> [2].
*About the Outreachy program*
Outreachy offers three-month internships to work remotely in Free and Open
Source Software (FOSS), coding, and non-coding projects with experienced
mentors. These internships run twice a year–from May to August and December
to March. Interns are paid a stipend of USD 7000 for the three months of
work. Interns often find employment after their internship with Outreachy
sponsors or jobs that use the skills they learned during their internship.
This program is open to both students and non-students. Outreachy expressly
invites the following people to apply:
* Women (both cis and trans), trans men, and genderqueer people.
* Anyone who faces under-representation, systematic bias, or discrimination
in the technology industry in their country of residence.
* Residents and nationals of the United States of any gender who are
Black/African American, Hispanic/Latinx, Native American/American Indian,
Alaska Native, Native Hawaiian, or Pacific Islander.
See a blog post highlighting the experiences and outcomes of interns who
participated in a previous round of Outreachy with Wikimedia <
https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-an…>
[3]
*Tips for mentors for proposing projects*
* Follow this task description template when you propose a project in
Phabricator: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4]. Add
#Outreachy-Round-25 tag.
* Project should require an experienced developer ~15 days and a newcomer
~3 months to complete.
* Each project should have at least two mentors, with one of them holding a
technical background.
* Ideally, the project has no tight deadlines, a moderate learning curve,
and fewer dependencies on Wikimedia's core infrastructure. Projects
addressing the needs of a language community are most welcome.
* If you don't have an idea in mind and would like to pick one from an
existing list, check out these projects: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects/> [4]
* To learn more about the roles and responsibilities of mentors, visit our
resources on MediaWiki.org: <
https://www.mediawiki.org/wiki/Outreachy/Mentors> [5].
We look forward to your participation!
Cheers,
Srishti
[1] https://www.outreachy.org/
[2] https://phabricator.wikimedia.org/T313361
[3]
https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-an…
[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/
[5] https://www.mediawiki.org/wiki/Outreachy/Mentors
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hey all,
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[0]. 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[1].
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
on Phabricator.[2]
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
weeks.
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
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins>
[1]: <https://www.mediawiki.org/wiki/Backporting_fixes>
[2]: <https://phabricator.wikimedia.org/project/board/5694/>
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
is received.
Deployment plan:
* 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
Hi all,
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
channels.
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!
Strainu
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
<https://www.mediawiki.org/wiki/Development_policy#Implementation%20policies>.
Issues may arise particularly when the class in question changes or PHP itself
is updated. The problem that prompted this change is T316601
<https://phabricator.wikimedia.org/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
methods.
--
Daniel Kinzler
Principal Software Engineer, Platform Engineering
Wikimedia Foundation
I haven't seen too much discussion about this, but i just wanted to remind
everyone that people who participate in mediawiki development (including
many third party extensions) are eligible to vote in the current Wikimedia
foundation board of trustees election, even if you don't edit any wikimedia
wiki. You just have to have made one commit. Commits to third party
mediawiki extensions not used by Wikimedia wikis count (including some
hosted at github). The Wikimedia Foundation is the largest contributor to
MediaWiki core, and the trustees control the direction of the Wikimedia
Foundation. Hence your vote (indirectly) determines the direction of
MediaWiki software!
There is an unofficial list of eligible developers at
https://i-want-to-vote.toolforge.org . I encourage anyone who participates
in development of software in the mediawiki ecosystem to check if they are
on the list. Even if you are not on that list you may still be eligible.
You can learn more about the candidates at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Candida…
. In particular, many of you might already know legoktm who is one of the
candidates and is very active in the mediawiki developer community. You can
vote now up until september 6 (however some eligible people must register
to vote before sept 2). The link to vote is
https://meta.wikimedia.org/wiki/Special:SecurePoll/vote/393 . People who
are eligible to vote due to software development must pre-register via
email before that link works for them and they must do so 4 days before the
end of the election. See https://i-want-to-vote.toolforge.org for details.
The full official list of eligibility criteria is at
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Voter_e…
. The key point for software developers, is you only have had to make 1
commit between Jan 5 and july 5, to any gerrit repo, any toolforge tool
repo (including those outside gerrit), or any mediawiki extension/skin on
MWStake's list of mediawiki extensions/skins developed outside of gerrit.
If the above doesn't describe you, there are also other criteria that can
make you eligible, like if you have made lots of edits to
https://mediawiki.org or https://translatewiki.net, maintain or contribute
to "tools, bots, user scripts, gadgets, and Lua modules on Wikimedia
wikis", or "substantially engaged in the design and/or review processes of
technical development related to Wikimedia." or are employed by the
Wikimedia foundation or an affiliate of Wikimedia. Check the official rules
for the full list.
Anyways i encourage everyone to vote who is eligible. People who are voting
by virtue of being a software developer MUST register 4 days before the end
of the election (i.e. sept 2), so if that's you, be sure to do it in time.
See the official rules or https://i-want-to-vote.toolforge.org for details.
--
Bawolff
p.s. Just to clarify, this isn't an official email, i just wanted to ensure
that the wider mediawiki developer community was aware of this as i suspect
many eligible developers may be unaware they are allowed to vote.
Hello,
We have a proposal to make small adjustments to the MediaWiki database
policy which would make abstract schema an explicit requirement.
Abstract schema was approved by TechCom in
https://phabricator.wikimedia.org/T191231 and now core and all WMF-deployed
extensions have migrated to abstract schema.
You can find the proposal in here. Please take a look and comment:
https://www.mediawiki.org/wiki/Talk:MediaWiki_database_policy
If there are no major objections by the end of August 2022, I will codify
this into the policy.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>