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
Hi all!
In my opinion, MediaWiki’s PHPCS ruleset feels largely rooted in an older
version of PHP, where static type declarations (formerly known as “type
hints”) did not exist. As we move towards more modern code, I think some
rules should be relaxed, and others adjusted. More specifically, I’d like
to know if most people agree with the following propositions and conclusion:
Proposition 1: *Some code is sufficiently documented by names and types*,
and does not require additional documentation. Cases where additional
documentation is required do certainly exist, but they can only be
identified by human reviewers, not by automated tools.
You can see this in our existing code wherever a doc comment specifies only
a type (with @var, @param, or @return), but no additional text. For
example, in CreditsAction
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/actions…>,
nobody needs to be told that the LinkRenderer will be used to render links,
or that the UserFactory creates User objects:
class CreditsAction extends FormlessAction {
/** @var LinkRenderer */
private $linkRenderer;
/** @var UserFactory */
private $userFactory;
Likewise, it’s not necessary to explain in great detail that the string
returned by LinksTable::getTableName()
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/deferre…>
is the table name, that the $actor parameter of ActorCache::remove(
UserIdentity $actor )
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/user/Ac…>
represents the actor to remove from the cache, or what the meaning of
the Message
$m and returned MessageValue are in Message\Converter::convertMessage()
<https://gerrit.wikimedia.org/g/mediawiki/core/+/de752f45af/includes/Message…>
:
/**
* Convert a Message to a MessageValue
* @param Message $m
* @return MessageValue
*/
public function convertMessage( Message $m ) {
(I want to clarify that in this last example I’m only talking about the
@param and @return tags that already don’t have any prose text. While the
method comment “Convert a Message to a MessageValue” might also be
considered redundant, I think this would be more contentious, and I’m not
advocating for removing that today.)
Proposition 2: *Adding types as static types is generally preferable.*
Unlike doc comments, static types are checked at runtime and thus
guaranteed to be correct (as long as the code runs at all); the small
runtime cost should be partially offset by performance improvements in
newer PHP versions, and otherwise considered to be worth it. New code
should generally include static types where possible, and existing code may
have static types added as part of other work on it. I believe this
describes our current development practice as MediaWiki developers.
Note that some older MediaWiki classes are considered unsuitable for static
types, and should only be used in comments; this is expected to help in a
future migration away from these classes (see T240307#6191788
<https://phabricator.wikimedia.org/T240307#6191788>).
Proposition 3: *Where types can be losslessly represented as PHP static
types, types in doc comments are unnecessary.* When doc comments are
considered necessary for actual documentation beyond types, then the type
is generally still included (and Phan will check that it matches the static
type), but when no further documentation is needed (see proposition 1
above), then the @var, @param, etc. doc comment can be omitted.
Note that depending on the PHP version, not all types can be losslessly
represented as PHP static types yet (e.g. union types and mixed both need
to wait for PHP 8.0, null and false for PHP 8.2); in such cases, doc
comments can remain necessary.
Conclusion: *We should update our PHPCS ruleset to require fewer doc
comments.* Exact rules are probably to be decided, depending on how much
work we’re willing to put into the sniff implementations (e.g. is it
feasible to require /** @param */ doc comments only if a parameter has no
static type?), but generally, I argue that we want code such as the
following to be allowed by our standard PHPCS ruleset:
class CreditsAction extends FormlessAction {
private LinkRenderer $linkRenderer;
private UserFactory $userFactory;
/** Convert a Message to a MessageValue */
public function convertMessage( Message $m ): MessageValue {
When doc comments are still necessary or at least beneficial because the
type alone isn’t enough information, it’s up to humans to decide this while
writing the code or point it out during code review.
What do people think about this? :)
PS: In PHP 8, we could abbreviate some of this code even more using
constructor property promotion:
class CreditsAction extends FormlessAction {
public function __construct(
Page $page,
IContextSource $context,
private LinkRenderer $linkRenderer,
private UserFactory $userFactory
) {
parent::__construct( $page, $context );
}
(Again, I’m not saying that all code should look like this – but I think we
have plenty of existing code that effectively carries no additional
information in its documentation, and which could be converted into this
form without losing anything.)
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
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.
Hello all,
Here is a quick update on Outreachy Round 25: we recently concluded the
final call for projects and mentors and are now promoting 6 projects led by
14 mentors. If you know someone who cleared the Outreachy's initial
eligibility check, encourage them to explore the Wikimedia projects below:
- Create a web application for editing Toolhub records, mentored by:
Slavina Stefanova, Damilare Adedoyin, Roy Smith
- Develop features for Wiki Loves Monuments app, mentored by: Ederporto,
Mike Peel
- Rewrite Imagebulk tool to scale up, mentored by: Jay Prakash,
Sudhanshu Gautam
- Write a Ruby gem for analyzing Wikidata edits, mentored by: Sage Ross,
Will Kent
- Develop a web app for patrolling based on the new ML-based service to
predict reverts, mentored by: Diego Saez-Trumper, Muniza A.
- Hybrid event production for QueeringWikipedia 2023, mentored by: Z.
Blace, Owen Blacker, Freddy eduardo
If you are interested in any of these projects, you can either subscribe to
the related Phabricator tickets or share your ideas and suggestions in a
comment.
Learn more here: <https://www.mediawiki.org/wiki/Outreachy/Round_25> [1]
Cheers,
Srishti
[1] https://www.mediawiki.org/wiki/Outreachy/Round_25
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi,
Over two years ago[1] I worked on redesigning the Codesearch UI to make
it easier to browse and filter. It didn't go anywhere for various
reasons[2], but in June Krinkle picked it up again and I've now deployed
his rewrite[3], please try it out:
https://codesearch-beta.wmcloud.org/
You can insert "-beta" into the URL of any normal codesearch result and
it should just work.
Here's an overview of the changes:
* Switching backends keeps the search query
* Sidebar for easy skipping of many results from one repo
* Implement fuzzysort and typeahead autocompletion for the
repo selector dropdown
* Generate a report in the format of a Phabricator checklist
* Add search query to the document title (browser tab)
* Implement a pulsating "placeholder" state
* Optimise fetching of "repos" config data by caching this server-side
* Fix advanced options being hidden by adblockers
And there's more, you can read Krinkle's commit message[3] for the full
list and links to tasks.
Please report bugs you find in the Codesearch Phabricator project[4] (or
submit a patch!). If all goes well I'd like to switch over the main
domain to the new interface near the end of the year.
[1]
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
[2] lack of time and basing on top of experimental technology
[3] https://gerrit.wikimedia.org/r/c/labs/codesearch/+/804785/
[4] https://phabricator.wikimedia.org/project/view/3158/
Thanks,
-- Kunal / Legoktm
Hello everyone,
The last & final feedback session on the "Small wiki toolkits" (SWT)
workshop series is coming up - it will take place on Friday, October 28th,
at 16:00 UTC. You can find more details on the workshop and a link to join
here: <
https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#Upcoming:_Fin…>
[1].
This workshop will gather feedback on the SWT workshop series around bots
and scripts development, ongoing since January 2022. There will be a
discussion around the following:
- Overall feedback on the workshop series
- Technical topics you would like to see the SWT team focus on by
running workshops or developing resources in 2023
- Your preferred learning formats
This session does not require attendance in previous workshops to
participate. We look forward to your participation!
Best,
Srishti
On behalf of the SWT Workshops Organization team
[1]
https://meta.wikimedia.org/wiki/Small_wiki_toolkits/Workshops#Upcoming:_Fin…
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
This email is a summary of the Wikimedia production deployment of
1.40.0-wmf.7
Conductor: Jaime Nuche
Backup Conductor: Antoine Musso
Blocker Task: T320512 <https://phabricator.wikimedia.org/T320512>
Current Status: Live everywhere <https://versions.toolforge.org/>
_____
*📊 Stats*
Sparklines comparing the last 5 trains.
213 Patches ▁▆█▃▁
0 Rollbacks ██▁█▁
0 Days of delay █▁▁▁▁
0 Blockers ▂█▂█▁
Moar stats in the train-stats repo
<https://gitlab.wikimedia.org/repos/releng/train-stats>
_____
*🎉 Traintastic Folks ✨*
It was a quiet week. And—wow—a release with no blockers, no delays, and no
rollbacks!
So thanks to the folks who backported some needed changes over the past
week:
- *Tim Starling* for handling multi-byte unicode capitalization changes
between php7.2 and php7.4: https://phabricator.wikimedia.org/T292552
- *Amir Sarabadani *for finishing work to make running maintenance
scripts that interact with the database better and safer:
https://phabricator.wikimedia.org/T298485
Until next train!
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hi,
The method ContentHandler::getDataForSearchIndex() is used by (non-core) MW
SearchEngine implementations and was added in MW 1.28 to gather the data to
be indexed.
In 1.40 this signature will change to let SearchEngine implementations pass
an optional RevisionRecord param
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/832957/10/includes/conten…>
to clarify what revision is being indexed (instead of assuming that the
"latest" was requested).
This is a breaking change if you maintain a ContentHandler subclass and
have overridden the getDataForSearchIndex() method, you will have to change
your method signature from:
public function getDataForSearchIndex( WikiPage $page, ParserOutput
$output, SearchEngine $engine )
to
public function getDataForSearchIndex( WikiPage $page, ParserOutput
$output, SearchEngine $engine, RevisionRecord $revision = null )
If you own a SearchEngine implementation and rely on
ContentHandler::getDataForSearchIndex() this is not a breaking change but
it is advised to pass this new RevisionRecord parameter when calling it.
Relatedly the hook SearchDataForIndex
<https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex> will be
deprecated (silently) and SearchDataForIndex2
<https://www.mediawiki.org/wiki/Manual:Hooks/SearchDataForIndex2> should be
used instead.
Please let me know if you have questions/strong objections to this approach.
--
David Causse