Yesterday there was a conversation about code review on irc and among other
things, how sometimes patches can get "stuck".
I had an idea for a way to improve things. I'm not sure if it is a good
idea, but there's only one way to find out.
So without further ado, announcing the Code Review Patch Board:
https://www.mediawiki.org/wiki/Code_review/patch_board
In short - each person is allowed to list one of their patches on the board
that they would really like to see reviewed. You can only list one patch at
a time, and it should be a patch that you have been unable to get review
for for at least a week through normal means. See the page for the full
list of guidelines.
I encourage people to give it a try. Add a patch you wrote that you cannot
get a review for. Or if you have +2 rights, try giving some love to these
underloved patches.
I would also love to hear feedback on the general idea as well as the
current guidelines.
To repeat, the url is:
https://www.mediawiki.org/wiki/Code_review/patch_board
Thanks,
bawolff
TL;DR: The legacy Mobile Content Service is going away in July 2023. Please
switch to Parsoid or another API before then to ensure service continuity.
Hello World,
I'm writing about a service decommission we hope to complete mid-July 2023.
The service to be decommissioned is the legacy Mobile Content Service
("MCS"), which is maintained by the Wikimedia Foundation's Content
Transform Team. We will be marking this service as deprecated soon.
We hope that with this notice, people will have ample time to update their
systems for use of other endpoints such as Parsoid [1] (n.b., MCS uses
Parsoid HTML).
The MCS endpoints are the ones with the relative URL path pattern
/page/mobile-sections* on the Wikipedias. For examples of the URLs see the
"Mobile" section on the online Swagger (OpenAPI) specification
documentation with matching URLs here:
https://en.wikipedia.org/api/rest_v1/#/Mobile
== History ==
The Mobile Content Service ("MCS") is the historical aggregate service that
originally provided support for the article reading experience on the
Wikipedia for Android native app, as well as some other experiences. We
have noticed that there are other users of the service. We are not able to
determine all of the users, as it's hard to tell with confidence from the
web logs.
The Wikimedia Foundation had already transitioned the Wikipedia for
Android and iOS apps to the newer Page Content Service ("PCS") several
years ago. PCS has some similarities with MCS in terms of its mobility
focus, but it also has different request-response signatures in practice.
PCS, as with MCS, is intended to primarily satisfy Wikimedia
Foundation-maintained user experiences only, and so this is classified with
the "unstable" moniker.
== Looking ahead ==
Generally, as noted in the lead, we recommend that folks who use MCS (or
PCS, for that matter) switch over to Parsoid for accessing Wikipedia
article content programmatically for the most predictable service.
The HTML produced by Parsoid has a versioned specification [2] and because
Parsoid is accessed regularly by a number of components across the globe
tends to have fairly well cached responses. However, please note that
Parsoid may be subject to stricter rate limits that can apply under certain
traffic patterns.
At this point, I do also want to note that in order to keep up with
contemporary HTML standards, particularly those favoring accessibility and
machine readability enhancements, Parsoid HTML will undergo change as we
further converge parsing stacks [3]. Generally, you should expect iteration
on the Parsoid HTML spec, and of course as you may have come to appreciate
that the shape of HTML in practice can vary nontrivially wiki-by-wiki as
practices across wikis vary.
You may also want to consider Wikimedia Enterprise API options, which range
from no cost to higher volume access paid options.
https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access
== Forking okay, but not recommended ==
Because MCS acts as a service aggregate and makes multiple backend API
calls, caveats can apply for those subresources - possibility of API
changes, deprecation, and the like. We do not recommend a plain fork of MCS
code because of the subresource fetch behavior. This said, of course you
are welcome to fork in a way compatible with MCS's license.
== Help spread the word ==
Although we are aware of the top two remaining consumers of MCS, we also
are not sure who else is accessing MCS and anticipate that some downstream
tech may break when MCS is turned off. As we are cross-posting this
message, we hope most people who have come to rely upon MCS will see this
message. Please feel free to forward this message to contacts if you know
they are using MCS.
== Help ==
Although we intend to decommission MCS in July 2023, we would like to share
resources if you need some help. We plan to hold office hours in case you
would like to meet with us to discuss this or other Content Transform Team
matters. We will host these events on Google Meet. We will provide notice
of these office hours on the wikitech-l mailing list in the coming weeks
and months.
Additionally, if you would like to discuss your MCS transition plans,
please visit the Content Transform Team talk page:
https://www.mediawiki.org/wiki/Talk:Content_Transform_Team
Finally, some Content Transform Team members will also be at the Wikimedia
Hackathon [4] if you would like some in-person support.
Thank you.
Adam Baso (he/him/his/Adam), on behalf of the Content Transform Team
Director of Engineering
Wikimedia Foundation
[1] https://www.mediawiki.org/wiki/Parsoid
[2] https://www.mediawiki.org/wiki/Specs/HTML
[3] https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Updates
[4] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023
Results: https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2023
🥰 Thanks to everyone who took the time to respond to the survey!
The developer satisfaction survey results show what's important to our
developer community—the parts of the developer experience that work well,
and the parts that need more resources to improve.
➡️ Read it. Talk about it. And ask questions! (please ;))!
🎉 Huge thanks to the Wikimedia Research Team[0] for helping Release
Engineering build the survey and process the data. In particular, Yu-Ming
Liou for survey-building expertise. And Caroline Myrick who was a hero
processing, exploring, graphing, and patiently explaining all the data.
<3
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/Wikimedia_Research>
As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.38 as of today, Friday June 30,
2023.
1.38.7 is expected to be the last release for this branch.
This means that MediaWiki 1.38 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade either to MediaWiki 1.39 (LTS), which will be
supported until November 2025 or to 1.40 (released today), which will be
supported until June 2024.
Thanks!
Sam Reed
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi all,
On Friday we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
- 1.35.11
- 1.38.7
- 1.39.4
This will resolve three minor security issues in MediaWiki core, along with
bug fixes included for maintenance reasons. This includes various patches
for PHP 8.0, PHP 8.1 and PHP 8.2 support.
Due to the low severity of two of the patches, they already exist in the
respective release branches in git.
We will make the fixes available in the respective release branches (plus
1.40 which will also be released tomorrow) 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, 1.38 becomes end of life (EOL) tomorrow, June 30, 2023.
1.38.7 is therefore expected to be the last release for this branch. It is
recommended to upgrade to 1.39 (the next LTS after 1.35), which will be
supported until November 2025, or the newly released 1.40, which will be
supported until June 2024.
[1] https://www.mediawiki.org/wiki/Version_lifecycle
Hi folks,
Starting *next week (Week 25)*, and for a period of *at least two weeks*,
test.wikipedia.org will be hosted on our Mediawiki-On-Kubernetes
infrastructure.
This is required for our Quality and Test Engineering team to run their
full test suite against this infrastructure and check where it matches
expectations, and where we still have some work to do.
This task is tracked on Phabricator
<https://phabricator.wikimedia.org/T337489> as part of the larger MW-On-K8s
<https://phabricator.wikimedia.org/tag/mw-on-k8s/> project.
As always, you can reach out to us on the public #wikimedia-sre channel on
IRC (instructions for joining here
<https://meta.wikimedia.org/wiki/IRC/Instructions>), file a subtask to
T337489 <https://phabricator.wikimedia.org/T337489> in case of issue, or
reply to me with any questions.
Thank you,
--
Clément Goubert (they/them)
Senior SRE
Wikimedia Foundation
Hello everyone,
The Committee has finished selecting its new members. The new committee
candidates are (in alphabetical order):
- Amir Sarabadani
- Egbe Eugene Agbor (Eugene233)
- Jayprakash12345
- MusikAnimal
- Nuria Ruiz (Nurieta)
Auxiliary members will be (alphabetically):
- Effie Mouzeli
- Joris Darlington Quarshie
- Martin Urbanec
- SD0001
- Tony Thomas (01tonythomas)
You can read more information about the members at [1]. List of changes
from the last term:
- Jay is joining the main committee (served as auxiliary member for
several years)
- I'm moving to the aux committee
- SD0001 and Joris Darlington Quarshie are joining the aux committee
- Huji and Luke081515 are leaving the aux committee
This is not the final structure. According to the CoC [2], the current
committee publishes the new members and call for public feedback for *six
weeks* and after that, the current committtee might apply changes to the
structure based on public feedback.
Please let the committee know (via techconduct(a)wikimedia.org) if you have
any concern regarding the members and its structure until *30 July 2023*
and after that, the new committee will be in effect and will serve for a
year.
[1]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee/Members/Candidates
[2]
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee#Selection_of_new_m…
Martin Urbanec, on behalf of the Code of Conduct Committee