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! :)
// sorry for cross-posting
Hello everyone,
Here is another change from WMDE’s Technical Wishes team concerning syntax
highlighting:
Soon, line numbers will be shown in wikitext editors when you have the
syntax highlighting feature (CodeMirror
<https://www.mediawiki.org/wiki/Extension:CodeMirror> extension)
enabled.[1] The change will make it easier to detect line breaks and to
refer to a particular line in discussions. More information can be found on
this project page. [2]
We plan to deploy this with this week’s Mediawiki train, so it should be on
wikis from April 13-15. As a first step, it will be available on the
template namespace only. Deployment on other namespaces is planned for the
near future.
If you have any feedback, please let us know on the project’s talk page.
[3] We hope line numbering will be useful to you!
Johanna
for the Technical Wishes team
[1] https://www.mediawiki.org/wiki/Extension:CodeMirror
[2] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Line_Numbering
[3]
https://meta.wikimedia.org/wiki/WMDE_Talk_Technical_Wishes/Line_Numbering
--
Johanna Strodt
Projektmanagerin Kommunikation Communitys Technische Wunschliste
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
[Moving to wikitech-l; mediawiki-l is a little off-topic.]
On Mon, 26 Jul 2021 at 21:27, Yaron Koren <yaron57(a)gmail.com> wrote:
> Hi,
>
> I've been trying to get rid of the ESLint warnings for the JavaScript code
> in some of my extensions, when they go through Jenkins validation. One
> warning that appears fairly often is this one:
>
> Where possible, maintain application state in JS to avoid slower DOM
> queries
> no-jquery/no-class-state
>
>
> I'm not sure if this is a warning that's specific to Wikimedia code, but
> doing a web search on it brings up this Wikimedia help page as the only
> real result:
>
>
> https://github.com/wikimedia/eslint-plugin-no-jquery/blob/master/docs/rules…
>
Yes, we forked the dead "jquery" upstream eslint plugin and have expanded
it significantly. In general, the plugin's purpose
<https://www.npmjs.com/package/eslint-plugin-no-jquery> is to discourage
use of jQuery functions, especially where the functions are deprecated or
have faster native equivalents. (Almost all uses of jQuery are no longer
necessary given that the vast majority of the Web only runs on
modern-enough browsers.)
This page is rather confusing. It says that the warning comes when calling
> either hasClass() or toggleClass() on a jQuery element. That part makes
> sense, but then the suggested alternatives are strange. The page says that
> the following are some examples of bad code:
>
> $( 'div' ).hasClass();
> $div.hasClass();
>
> In their place, it suggests the following:
>
> hasClass();
> [].hasClass();
> div.hasClass();
>
No, it doesn't. It says that our code is clever enough to not think that
these false positives are issues that you need to fix. It's not saying you
should use a method called hasClass(); it's saying that you should maintain
state inside JS; this is principally a performance/code smell test.
If your code is triggered from a non-JS DOM (e.g. painted from PHP), the
first time you grab state from the DOM is unavoidable (and so you'd use an
inline disable), but thereafter you should keep track of such details in
JS. An example of this is in the initialisation code for Notifications
("Echo"), where it has to grab the state from the DOM
<https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/HEAD/modules/ext…>
for a couple of items, but does so only once.
Sorry that this is confusing! We could put together a narrow JS tips and
tricks page and link to that from the linter, but most of these have been
fixed over the years since we introduced this in Wikimedia production code
so there's not been much call.
J.
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
For performance sensitive tight loops, such as parsing and HTML
construction, to get the best performance it's necessary to think
about what PHP is doing on an opcode by opcode basis.
Certain flow control patterns cannot be implemented efficiently in PHP
without using "goto". The current example in Gerrit 708880
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/708880/5/includes/Html.ph…>
comes down to:
if ( $x == 1 ) {
action1();
} else {
action_not_1();
}
if ( $x == 2 ) {
action2();
} else {
action_not_2();
}
If $x==1 is true, we know that the $x==2 comparison is unnecessary and
is a waste of a couple of VM operations.
It's not feasible to just duplicate the actions, they are not as
simple as portrayed here and splitting them out to a separate function
would incur a function call overhead exceeding the proposed benefit.
I am proposing
if ( $x == 1 ) {
action1();
goto not_2; // avoid unnecessary comparison $x == 2
} else {
action_not_1();
}
if ( $x == 2 ) {
action2();
} else {
not_2:
action_not_2();
}
I'm familiar with the cultivated distaste for goto. Some people are
just parotting the textbook or their preferred authority, and others
are scarred by experience with other languages such as old BASIC
dialects. But I don't think either rationale really holds up to scrutiny.
I think goto is often easier to read than workarounds for the lack of
goto. For example, maybe you could do the current example with break:
do {
do {
if ( $x === 1 ) {
action1();
break;
} else {
action_not_1();
}
if ( $x === 2 ) {
action2();
break 2;
}
} while ( false );
action_not_2();
} while ( false );
But I don't think that's an improvement for readability.
You can certainly use goto in a way that makes things unreadable, but
that goes for a lot of things.
I am requesting that goto be considered acceptable for micro-optimisation.
When performance is not a concern, abstractions can be introduced
which restructure the code so that it flows in a more conventional
way. I understand that you might do a double-take when you see "goto"
in a function. Unfamiliarity slows down comprehension. That's why I'm
suggesting that it only be used when there is a performance justification.
-- Tim Starling
Hello,
We will upgrade our Gerrit to [version 3.3]. We have scheduled it on
Tuesday, August 3rd at 16:00 UTC. We will first upgrade the [Gerrit
replica] then the primary server. The service will thus be unavailable for
a few minutes while we conduct the operation and restart the service.
The July 19th upgrade took a bit longer than expected since we were trying
our runbook for the first time. We have since improved our documentation
and addressed a few configuration glitches we had.
This upgrade comes with a new feature: "Attention Set". It replaces change
*assignees* with a list of people that are expected to act on the change.
It helps better differentiate changes you have already reviewed from the
one you have to review or amend. The feature is nicely explained on
upstream documentation page:
http://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/user…
Ahmon, Antoine, Brennen
Release Engineering
[version 3.3] https://www.gerritcodereview.com/3.3.html
[Gerrit replica]
https://wikitech.wikimedia.org/wiki/Gerrit-replica.wikimedia.org
Upgrade task: https://phabricator.wikimedia.org/T262241
Hello all,
We invite you all to sign up for Toolhub's Quality Signal sessions!
Toolhub <https://meta.wikimedia.org/wiki/Toolhub> [1] is a
community-authored catalog of Wikimedia tools. On Toolhub, you will be able
to discover new tools in the Wikimedia ecosystem, promote their use in your
wiki community, and help improve them by contributing data. Toolhub's first
release is planned around Wikimania 2021.
The Toolhub team is currently working on identifying quality indicators
through conversations with tool users and developers. As a tool user, how
do you know which tool is reliable, useful, and safe to use? As a tool
maintainer, what makes it attractive to you to contribute to an existing
tool? What information are you looking for to decide whether to join a tool
project? We hope that these sessions will help gather quality indicators
for tools and provide valuable insight toward developing new features to
convey the quality.
Want to organize a quality signal session in your community in August/early
September? Please get in touch on the talk page or sign-up for an already
planned session by adding your name below it: <
https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions> [2].
Your feedback, thoughts, ideas would be valuable!
If you are attending Wikimania, we are running a few introductions and a
feedback session as part of the unconference. Learn more here: <
https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub> [3].
Cheers,
Srishti
On behalf of the Toolhub team
[1] https://meta.wikimedia.org/wiki/Toolhub
[2] https://meta.wikimedia.org/wiki/Toolhub/The_Quality_Signal_Sessions
[3] https://wikimania.wikimedia.org/wiki/2021:Unconference/Toolhub
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all,
This email is a reminder to start proposing projects and sessions for this
year’s Wikimania hackathon, taking place on August 13th (the first day of
Wikimania). You may have already seen the announcement email last week with
all the details.
This year’s hackathon will take place in a 24 hrs format covering all time
zones. You can start proposing a session or a project by following the
guidelines here: <
https://wikimania.wikimedia.org/wiki/2021:Hackathon#Propose_a_project_or_a_…>
[1].
We also encourage folks to reuse the video of a previously recorded session
(in lecture format) to organize a watch party-style session. And, you can
pause during or after for questions and discussions. That way, you have to
do less prep, and one can watch your session at any time during the event.
There isn't a specific focus area proposed this time, so your session or
project needn't fit under a theme. Anything that involves MediaWiki
development or covers a technical area in the Wikimedia ecosystem. Plus, we
welcome sessions that would be helpful to newcomers–new to the event, our
technical spaces, or projects.
If you have any questions, feel free to use the related talk page to
contact the organizing team or join the community conversation on Telegram:
<https://t.me/wikimaniachat> [2].
We look forward to your participation!
Cheers,
Srishti
On behalf of the Wikimania Hackathon organizing team
[1]
https://wikimania.wikimedia.org/wiki/2021:Hackathon#Propose_a_project_or_a_…
[2] https://t.me/wikimaniachat
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
The 1.37.0-wmf.12[0] train is currently blocked at group1 by an UBN bug:
T287704 [1].
The culprit seems to be [2] which added strict type checking to some
methods that are being called in a disagreeable manner from LUA code. For
the short time that wmf.16 was deployed to all wikis, errors were occurring
on at least svwiki and yuewiki at a rate of 900+ fatals per minute.
A clean revert of the offending patch isn't possible because other code
built on top of it. For now at least it would appear that the train is
blocked. Any assistance with resolving the issue is appreciated as always.
To keep up with the most current status please watch the train blocker
task[3] in Phabricator.
---
- 💕- Your humble train conductor.
1. https://phabricator.wikimedia.org/T287704
2. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/704998
3. https://train-blockers.toolforge.org/
Hi all,
This email is of interest to you only if you're a user of the "Wikimedia
Debug" browser extension. If you're not, you can safely skip it.
As the more attentive might have noticed, the Wikimedia Debug browser
extension started offering a new option in the drop-down menu, besides the
usual mwdebug servers, labeled "k8s-experimental". That is, as the name
suggests, a very experimental setup of mediawiki running on kubernetes and
is not *yet* a place where you will be able to test your releases.
Right now, that installation is a work in progress, but nonetheless it
seemed important to us to have a way to browse the wikis from the
installation running on kubernetes while we iron out bugs in preparation
for the actual migration of production traffic.
This installation can thus:
- run on outdated versions of mediawiki (although we're trying to follow
train releases).
- be down for extended periods of time while we debug something, without
warning.
It also doesn't support (yet) profiling via xhprof.
So while we welcome the curious to poke around at the performance and bugs
of the installation, it is not a suitable tool (yet) to debug your releases
on.
I will add filters where appropriate to avoid logs from this installation
from polluting your dashboards in the coming days, but in the meantime, if
you see a log line coming from a server with a strange name like
"mediawiki-pinkunicorn"... that's mediawiki running on kubernetes and you
can mostly ignore it!
You can follow our progress at https://phabricator.wikimedia.org/T283056
Cheers,
Giuseppe
--
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation