Hi,
Andre suggested mailing to this list about task T236671 [0]. It is about
a misleading error message issued when having senior moments and trying
to run "update.php against" a non-existing database.
The issue is not a big deal, but it may be possible to improve usability
without considerable effort. I cannot assess, though.
Thanks a lot for having a peep at this.
Cheers, Karsten
[0] https://phabricator.wikimedia.org/T236671
Hello,
I have deployed a change to Gerrit which makes it display the ongoing
CI/Zuul build if there is any.
If Jenkins jobs are running, you would see below the commit message some
gray chipset with the name of the Zuul pipeline (test, gate-and-submit
..). The Check tab shows the jobs details
(https://phabricator.wikimedia.org/F36925186).
By exposing the Zuul CI status directly in the Gerrit web UI, people
will notice a build error earlier. That also saves the hassle of having
to monitor https://integration.wikimedia.org/zuul/.
There are a few glitches:
* the way I have implemented it abuses the model proposed by Gerrit
and in progress jobs are always considered a SUCCESS but will be
marked as ERROR when they fail.
* code is entirely running in the client browser. It is unable to send
notifications or triggers any email when a build has failed. The
EarlyWarning bot by Kosta Harlan
<https://phabricator.wikimedia.org/J302> does it though)
* I am not a JavaScript developer per see but learned about TypeScript
for static analysis and rediscovered QUnit. So at least there are
some basic guarantees.
* there are surely a bunch of edge cases that I have not properly handled
The code for those that are curious is at
https://gerrit.wikimedia.org/g/operations/software/gerrit/+/refs/heads/depl…
If you see problems, JavaScript errors etc please paste them on
https://phabricator.wikimedia.org/T214068 :)
Antoine "hashar" Musso
Wikimedia Phabricator tasks have a "Priority" dropdown field (which is
not consistently used) with several discrete values, among them
"Lowest". See [1] for the full list of Priority field values.
Since [2], "Low" and "Lowest" priority share the same definition.
I propose to disable setting the "Lowest" Priority value in Phab tasks.
"Lowest priority" can sound demotivating / disrespectful ("there is
nothing that could be even less important"). However, bikeshedding
about changing the name of the value would ignore further observations:
* About half of the people who are most active in setting initial
Priority values do not ever set Priority to "Lowest"[3].
* There is no significant difference between median age of open tasks
with Low and with Lowest priority[4], thus nothing seems to get
realistically differentiated here.
* Personally I also assume Lowest priority is sometimes used instead
of honestly declining a task (means: "this is not a good idea"[5]).
But of course that is rather hard to prove.
If you have opinions and/or ideas how to interpret data differently,
please add them to https://phabricator.wikimedia.org/T228759 to keep
them in a single place - either as a text comment, or via "Award Token"
to express support or disagreement without adding words.
Thanks,
andre
[1] https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_leve…
[2] https://phabricator.wikimedia.org/T317533
[3] https://phabricator.wikimedia.org/T228759#6988320
[4] https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[5] https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
The mission of Wikimedia Performance is for our sites to transcend socioeconomic barriers around reliable and fast access to find and contribute knowledge. We provide tools and expertise to empower developers, and directly inform or undertake high-yield engineering projects. [1][2]
The below is a periodic introduction and summary of recent changes to our guides. If you haven't read these before, or if it's been more than six months, I recommend taking a fresh look. Especially if you work on frontend or backend components in a MediaWiki extension or MediaWiki core.
== *Current best practices* ==
The practices guides help set direction. Use them to guide new developments, or to identify areas for improvement in current code. If you're short on time, focus on the "Getting started" section atop each guide.
*Frontend*: https://wikitech.wikimedia.org/wiki/Performance/Guides/Frontend_performance…
* The introduction details the principles that drive our platform's architecture, and how to get the most out of it.
* Changed: The CSS "@embed" optimisation is now only recommended for very small icons (up to 0.3KB). The guide explains why and how.
*Backend*: https://wikitech.wikimedia.org/wiki/Performance/Guides/Backend_performance_…
* New "Getting started" section, with pointers to specific chapters for detailed guidance.
* Rewritten "Shared resources" chapter, now with a more accessible explanation of MySQL deadlocks and how to avoid them.
* Update "Multi-datacenter deployment" guidance. (No changes are needed to existing code.) We first adopted Multi-DC practices in 2015. WANObjectCache and JobQueue interfaces have gotten simpler since. Cross-DC purges and job queuing "just work", with no awareness or responsibility on calling code. MediaWiki now automatically pins a browser to the primary DC for a few seconds after publishing an edit. This allowed us to remove cross-DC complexity around the ChronologyProtector <https://doc.wikimedia.org/mediawiki-core/master/php/classWikimedia_1_1Rdbms…>.
== *Measuring* ==
The new "measure" guides help assess performance of existing code, and can help iterate development of proposed changes.
Frontend includes browser dev tools and continuous monitoring through dedicated perf testing infrastructure:
https://wikitech.wikimedia.org/wiki/Performance/Guides/Measure_frontend_per…
Backend includes flame graphs, benchmarking, and automatic Grafana stats if you adopt WANObjectCache:
https://wikitech.wikimedia.org/wiki/Performance/Guides/Measure_backend_perf…
== *More* ==
The above guides and an overview of datasets, tools, recommended Grafana dashboards, and infrastructure diagrams are available at:
https://wikitech.wikimedia.org/wiki/Performance
On behalf of the Performance Team,
-- Timo Tijhof.
[1] https://techblog.wikimedia.org/2018/12/12/why-performance-matters/
[2] https://www.mediawiki.org/wiki/Wikimedia_Performance_Team#Mission
The 1.40.0-wmf.27 version of MediaWiki is blocked[0].
The new version is currently deployed to group1, but can proceed no
further until this issue is resolved or triaged as irrelevant:
* Lcobucci\JWT\Signer\InvalidKeyProvided: Key cannot be empty
- https://phabricator.wikimedia.org/T321160
Once these issues are resolved train can resume.
Thank you for any help resolving these issues!
-- Your humble train toilers
[0]. https://phabricator.wikimedia.org/T330205
[1]. https://versions.toolforge.org/
I wrote a post, "CI: Get notified immediately when a job fails"[0], about new CI notification options for MediaWiki core/extension/skin developers.
tl;dr, if you want to get notified as soon as any test fails (instead of waiting for the entire set of jobs to finish) this is now possible.
Thanks to Antoine Musso & Martin Urbanec for their collaboration and support on this!
Feedback & contributions to the feature are very welcome; see the blog post for details.
Cheers,
Kosta
[0] https://phabricator.wikimedia.org/phame/post/view/302/ci_get_notified_immed…
Hi everyone!
Inspired by https://www.mediawiki.org/wiki/VisualEditor/Gadgets#Implementing_a_custom_c… I was trying to add a `<br />` into the VE using this command:
```
ve.init.target.getSurface().getModel().getFragment().insertContent( [ { type: 'break' }, { type: '/break' } ] );
```
While it actually inserted the line break in visual edit mode, there was not `<br />` in the wikitext after saving the page or switching to wikitext mode within the edit session.
I also tried to implement the whole "command/tool" in an extension, but the behavior was the same. The odd thing is that a `<br />` inserted in wikitext mode survives the round trip. The linear data model shows it as "alienInline" node then.
Any ideas why the official example didn't work for me?
Greetings,
Robert
Hello all,
As you may already know, the Wikimedia Hackathon 2023 will take place in
Technopolis, Athens, Greece, on May 19-21. This in-person event will gather
the global Wikimedia technical community to connect, hack, run technical
discussions, and explore new ideas.
*If you plan to join, please register as soon as possible.*
Registration for the Hackathon will be open until we reach the event's
maximum capacity [0]. If you plan to join, we encourage you to register as
soon as possible, as there are currently around ten slots left. We also
encourage you to book your travel and accommodation shortly. You will find
more information on the travel [1] and accommodation [2] pages. You are
also welcome to help us improve those pages by adding additional
information about Athens and how to travel there.
For people who already registered, remember to confirm your attendance by
filling out the additional field in the registration form (see the email
sent by hackathon(a)wikimedia.org on March 13). Please note that WMF's
scholarship process concluded in January, and aside from the 51 people who
got a scholarship confirmed, we cannot support people with funds or visa
documents. Therefore, most participants must organize their own travel to
stay in Athens.
This year's edition will focus on bringing together people who already
contribute to technical aspects of the Wikimedia projects, know how to find
their way around in the technical ecosystem, and can work or collaborate on
projects more autonomously. For people new to our technical environment,
there are other newcomers-friendly events you can join throughout the year
- feel free to improve the list. [3]
*You can organize a satellite event with your local community.*
For people new to the technical aspects of the Wikimedia projects or who
cannot attend the in-person event, a great option could be to organize an
autonomous, local satellite event to the Hackathon. These events can occur
before, during, or after the in-person event. If you are considering
running an event like this, contact your local community to get started! If
you need financial support, please note that the deadline to apply for the
current round of Rapid Funds is March 20 [4].
*Proposals for the in-person program are welcome until April 4.*
The Hackathon is organized as a participant-driven event and lives from the
active participation of its attendees. Because this year's edition is
focused on reconnecting with your technical community peers in person, most
of the program will take place onsite. You can propose a session by
creating a task on the Phabricator board. Find more information on the
Program page [5].
Similar to the satellite events, some online sessions, in parallel or ahead
of the event, may be organized autonomously by participants. In any case,
participants are free to work on their projects, whether in-person or
online, and connect to the technical community on the Hackathon channels
[6].
If you have any questions, feel free to use the Hackathon talk page or to
reach out to the organizers at hackathon(a)wikimedia.org.
Cheers,
Srishti
On behalf of the Hackathon organizing team
[0]
https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Participate#Registr…
[1] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Travel
[2] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Accommodation
[3] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Documentation#Event…
[4] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Satellite_events
[5] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Program
[6] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023/Connect
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>