Dear all,
It’s time for our third edition of the Coolest Tool Award!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local &
global solutions and enhance the experience for Wikimedia communities.
We’d like to invite you all to nominate your favorite & most used tools
and help us celebrate the people who create them!
As no one can possibly know all the cool tools out there, we’re looking
for some help and inspiration: please point us to the tools that you
think are great - for any reason you can think of!
Please go to https://meta.wikimedia.org/wiki/Coolest_Tool_Award
to recommend tools by October 27, 2021. You can nominate as many tools
as you want by filling out the form multiple times.
Thank you very much for your ideas & recommendation(s)!
The award is organized & selected by the Coolest Tool Academy 2021. We
plan to recognize the greatest tools in a variety of categories (for
examples, see last year’s categories). The award ceremony will take
place virtually again this year and we will provide more details soon
about the specific logistics and dates.
We will continue to spread the word over the next week, but if you get
the chance, please feel welcome to share this information with others
too!
Thanks :-)
Andre, for the Coolest Tool Academy 2021
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
Hi everyone,
tl;dr: External shell outs are now run via Shellbox. Any deployed code
needs to use Shellbox/BoxedCommand, and documentation is available to
help migrate.
To safely re-enable Score (LilyPond) on Wikimedia wikis, we developed
Shellbox, a way to run shell commands in a remote, isolated container.
This is (hopefully) a stronger level of isolation than we previously had
with firejail, since it's relying on Linux containers and Kubernetes to
do the isolation. At the same time, this helps us in moving towards
running MediaWiki on Kubernetes, as we don't want to include all these
external commands inside the MediaWiki container. For the most part, any
new shelling out to external commands needs to be done via Shellbox.
A lot of the design and rationale behind Shellbox is captured in the
RfC: <https://phabricator.wikimedia.org/T260330>.
In Wikimedia production, so far Score, Timeline, SyntaxHighlight and
Wikidata constraint regex checking are all using Shellbox. Details about
that and links to dashboards are available at
<https://wikitech.wikimedia.org/wiki/Shellbox>. The main things that are
left are media-handling code that extracts metadata: DjVu, PdfHandler
and PagedTiffHandler, which is tracked at
<https://phabricator.wikimedia.org/T289228>, and videoscaling
(TimedMediaHandler).
Some work has to be done in MediaWiki to make code compatible with
Shellbox, specifically switching to "BoxedCommand", which now has its
own documentation page:
<https://www.mediawiki.org/wiki/Manual:BoxedCommand>. BoxedCommand works
transparently whether you have a separate Shellbox service set up or
not. This is the preferred way to write new shellouts going forward,
though Shell::command() isn't officially deprecated yet. So far all
shellouts that are used in Wikimedia production have already been
converted except for TimedMediaHandler.
Looking forward, I think this also gives us a lot of flexibility in
using more external commands in the future. First, we're less tied to
whatever OS version MediaWiki is running on, as long as it can be
built/shipped in a container, we can use it. And secondly, it's probably
OK if external commands aren't super well behaved (e.g. use too much
memory) since they're no longer sharing the same resources as an
appserver (this shouldn't be interpreted as a free pass for super
inefficient stuff of course).
I tried to keep this summary short, and am intending to write a longer
blog post that explains some more history in detail. But if you have any
questions or something isn't clear, please ask!
-- Kunal
I'm confused about what the term "ltsrel" means. The way I understand it,
it *should* mean that the extension supports only Long Term Support
versions of MediaWiki. It would have a branch for every LTS version of
MediaWiki like REL1_31 and REL1_35, but not for REL1_32, REL1_33 or REL1_34.
However, on the Compatibility
<https://www.mediawiki.org/wiki/Compatibility#MediaWiki_extensions> page,
the rel and ltsrel policies are described as:
* release branches (key: rel): For every MediaWiki release, there is a
corresponding branch in the extension. So e.g. if you use MediaWiki 1.36,
you should use the REL1_36 branch of the extension.
* long-term support release branches (key: ltsrel): For every MediaWiki
release, there is a corresponding branch in the extension, following the
Version lifecycle release policy.
These sound exactly alike to me.
This email is a summary of the Wikimedia production deployment of
1.38.0-wmf.2.
- Conductor: Jeena Huneidi
- Backup: Dan Duvall
- Blocker task: T281166 <https://phabricator.wikimedia.org/T281166>
- Current Status: Live everywhere <https://versions.toolforge.org/>
*🔢 Numbers*
- 351 patches ▁▄▇██
- 1 rollback █▁█▁█
- 0 days of delay █▁█▁▁
- 8 blocking tasks ▆▃▃▁█
- Closest to the buzzer: 3.3 hours before branch cut
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/724202> a nice catch
by Reedy
*🚂🌈 Trainbow love*
This train was bound for glory thanks to:
- DannyS712
- Legoktm
- Kosta Harlan
- Samuel
- Krinkle
- Jon Robson
- Olga Vasileva
- Taavi Väänänen
- Petr Pchelko
- Zabe
Sincere trainbow appreciation to you all <3
With wikilove,
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
*tl;dr:* We renamed a few backport windows, but everything about the
process is staying the same. As always, the deployment calendar
<https://wikitech.wikimedia.org/wiki/Deployments> is up-to-date and
canonical.
___________
Computer science has two hard problems
<https://www.martinfowler.com/bliki/TwoHardThings.html>: cache
invalidation, naming things, and off-by-one errors🥁. There are three backport
windows <https://wikitech.wikimedia.org/wiki/Backport_windows> a day—each
window has a name—three opportunities a day to fail at hard problems.
Folks observed that the calendar used "morning" and "evening" as terms
relative to the US West coast. And that the terms "EU" and "European" were
(a) not the same thing and (b) not entirely correct. So I changed things:
- *UTC morning* – 11UTC/4PDT – previously named *European mid-day
backport window*
- *UTC evening* – 18UTC/11PDT – previously named *Morning backport
window*
- *UTC late* – 23UTC/16PDT – previously named *Evening backport window*
___________
Thanks to Kosta <https://phabricator.wikimedia.org/T290859> for the
suggestion and review.
<3
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2021-09): 240
Active Maniphest users (any activity) in (2021-09): 970
Task authors in (2021-09): 523
Users who have closed tasks in (2021-09): 287
Projects which had at least one task moved from one column to another on
their workboard in (2021-09): 279
Tasks created in (2021-09): 2162
Tasks closed in (2021-09): 1833
Open and stalled tasks in total: 48286
* Only open tasks in total: 47381
* Only stalled tasks in total: 905
Median age in days of open tasks by priority:
Unbreak now: 1
Needs Triage: 709
High: 969
Normal: 1522
Low: 2129
Lowest: 2202
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2021-09): 4
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Fri 01 Oct 2021 12:00:20 AM UTC)