Hello,
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.
Best regards,
Zoran.
P. S.: Happy weekend! :)
Hi everyone,
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. :)
Best regards,
Zoran
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