- User Since
- Oct 3 2014, 12:07 PM (441 w, 6 d)
- IRC Nick
- LDAP User
- Jérémie Roquet
- MediaWiki User
- Arkanosis [ Global Accounts ]
Oct 31 2022
Oct 30 2022
socksfinder now runs on Kubernetes.
Oct 7 2022
No worries, it was in my plans to migrate at some point. Plus I'll be facilitating a workshop on Toolforge and Kubernetes in late November, so that will provide me with a concrete use-case for illustration.
Nov 11 2019
- I'm a volunteer scripts, gadgets, bots and tools developer at frwiki and wikidata, and I do some occasional training for Scribunto beginners, even though I'm not very active in modules development.
- I have to say that, having done this stuff since 2009, I'm really happy with how things are improving from a third-party developer's perspective. That being said, there are significant remaining pain points, including:
- a lack of relevant metrics about who uses what and what depends on what;
- a lack of attention from upstream to the tools people actually use — which itself is the result of the previous pain point — resulting in these tools being regularly broken with nobody to fix them (this is getting better, but there's room for improvement);
- the inability to efficiently share and localize code across wikis;
- the frequent low bus factor or absence of proper maintainership for tools people actually use, which sometimes could be solved by resolving the previous pain point;
- the frequent diverging forks or competing implementations of highly valuable tools, which could be avoided by solving the same sharing problem;
- the completely inappropriate tooling for developing tools (scripts, gadgets, templates, modules…) on MediaWiki: it's widely recognized that software development highly benefits from using version control systems with branchs (eg. git), code review (eg. gerrit, pull requests), test suites, proper tagging and release systems, etc., yet most of the development done outside of the core of MediaWiki has none of these. I'm not calling for more custom-tailored tools within MediaWiki, but for more integration with existing tools, so that developers can use their tools of choice (which they are productive with and which improve without any cost for Wikimedia).
Oct 26 2019
To be honest, I can't remember why I'd be admin of this project; I don't even see what it does… I see I've received a few mails about it since the end of 2018 but never really paid attention to them…
Oct 6 2019
Apr 22 2019
Apr 3 2019
Sounds very cool, thanks!
Oct 29 2018
Oct 24 2018
Thanks @Krenair !
@Jdforrester-WMF : Hi! It looks like the toolbar is now gone on the beta cluster, but not on the English Wikipedia (I can't really tell for the French Wikipedia as it has been much hacked there). Does it mean that the timeline on this page has been postponed by one week and that I still have seven days to make sure the gadgets are working?
Oct 21 2018
@Whatamidoing-WMF : Hi! I've been willing to test the upcoming deployment to make sure that the gadgets currently used by many on the French Wikipedia still work if the classic edit toolbar is disabled. So, following the information on the page you linked to from my user talk page, I went today to the English Wikipedia on the beta cluster which is currently running 1.33.0-alpha (26665a6). Unfortunately, it looks like the classic edit toolbar has not been disabled there, so I'm unable to test the gadgets from the French Wikipedia as planned.
Aug 29 2018
Aug 13 2018
Jul 1 2018
Nov 28 2017
Nov 7 2017
I'm afraid the current implementation of HDT is not ready to handle more than 4 billions triples as it is limited to 32 bit indexes. I've opened an issue upstream: https://github.com/rdfhdt/hdt-cpp/issues/135
Nov 6 2017
Nov 5 2017
FWIW, I've just tried to convert the ttl dump of the 1st of November 2017 on a machine with 378 GiB of RAM and 0 GiB of swap and… well… it failed with std::bad_alloc after more than 21 hours of runtime. Granted, there was another process eating ~100 GiB of memory, but I thought it would be okay — so I'm proved wrong.
Aug 18 2017
Sorry if it has been discussed in the past, but couldn't such issues be addressed by switching to a non-backtracking regex engine such as Google's RE2?
Jun 26 2017
Jun 19 2017
Jun 13 2017
@Whatamidoing-WMF @Jdforrester-WMF : thank you. I don't understand why we don't wait for everything to be ready instead, but that should do it. That would be awesome if you could drop me an email once the beta cluster is ready, so that I don't miss the opportunity.
Jun 9 2017
Jun 8 2017
Am I the only one to think these numbers don't add up? @Jdforrester-WMF: do you think it is possible for local scripts to break these metrics?
Jun 7 2017
@Whatamidoing-WMF : I'm pretty confident most of them if not all are actually using the local gadget and neither the original toolbar nor another more recent one. There's some “tradition” of customizing this legacy toolbar on the French Wikipedia through one's common.js. Additionaly, no one changed their mind when shown the very useful page at https://www.mediawiki.org/wiki/Editor (though I'd admit it doesn't mean much).
What I don't know is how it'll break when the original toolbar it's more or less based on will disappear.
Jun 5 2017
Feb 14 2017
Jan 24 2017
Marvelous ! Thank you! :-)
Aug 21 2016
Aug 14 2016
Wonderful. I know have a working training scenario :)
Just a quick note: the issue described in T93489 still applies to gerrit-test.wmflabs.org when cloning through HTTP, ie. git review -s doesn't work, you have to install the commit hook manually.
Hi @Paladox and thanks for the info.
Aug 13 2016
I didn't know about the Gerrit testing instance. Thanks!
Hi @Danny_B and thanks for your kind reply.
Jul 29 2016
Apr 28 2016
Fix applied. Thank you!
Feb 17 2016
Dec 14 2015
I guess the “quick fix” for now is to replace the current
$notice = Html::inlineScript( Xml::encodeJsCall( 'document.write', array( $notice ) ) );
with something like
$notice = Html::inlineScript( Xml::encodeJsCall( '$('#content').prepend', array( $notice ) ) );
(not quite sure about how encodeJsCall works).
Nov 16 2015
@Trizek: we probably have the same issue with a bunch of features (most of functions defined in that Common.js, I guess), so please let me know about anything similar you know is not working.
The code handling this template is the BoiteDeroulante function in MediaWiki:Common.js . It's only called on $( document ).ready(), hence the issue.
Oct 26 2015
$ wget 'https://en.wikipedia.org/' -O -
--2015-10-26 16:20:00-- https://en.wikipedia.org/
Resolving en.wikipedia.org (en.wikipedia.org)... 2620:0:862:ed1a::1, 188.8.131.52
Connecting to en.wikipedia.org (en.wikipedia.org)|2620:0:862:ed1a::1|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://en.wikipedia.org/wiki/Main_Page [following]
--2015-10-26 16:20:00-- https://en.wikipedia.org/wiki/Main_Page
Reusing existing connection to [en.wikipedia.org]:443.
HTTP request sent, awaiting response... 500 Internal Server Error
2015-10-26 16:20:00 ERROR 500: Internal Server Error.
Aug 27 2015
Aug 25 2015
Aug 7 2015
I've seen anouncements on Wikitech-ambassadors about the document.write breaking change, but nothing about legacy gadgets which as far as the French Wikipedia is concerned breaks much more things.
May 11 2015
Hi @Dereckson, hi everyone,
Mar 11 2015
Mar 3 2015
Feb 11 2015
Dec 10 2014
Nov 15 2014
Oct 14 2014
Oct 3 2014
I wonder if we're really talking about the same tokens (CSRF vs auth)… But maybe phabricator uses auth token as CSRF tokens. Anyway, the result is the same:
I understand the need of a token for state-changing requests, not for read-only requests. Here, we want the end-user (who certainly wont always have an account, let alone a bot account) to get publicly available information about tasks (summary, state…).