This is still not fixed on mediawiki.org :/
There's definitely another task about the weird indenting...
The biggest restriction that the MediaWiki API faces is that it is limited by whatever the underlying MySQL (or sqlite/postgres/etc.) database can serve in a fast and indexed way. Are you suggesting that we write a layer that turns sparql/graphql queries into something to run against the MediaWiki database? Or would it be more like WDQS where the data is copied into something that is designed for sparql querying (blazegraph)?
Wed, Nov 22
Nice find :)
Works for me.
Would we be creating a new key every year then?
If/when https://meta.wikimedia.org/wiki/Wikidirectory is approved (or it looks likely to be approved) then it would make sense to buy the domain. At this time filing a bug is still premature.
Tue, Nov 21
Password reset spam is extremely annoying. There *has* to be a throttle.
Please this merge the task the other way, T121332 had WAY more useful instructions and information on it.
It might? I'm not sure tbh. We can keep this one open since it's a specific tech debt issue, and if fixing that bug happens to fix this one as well, that's great :)
@Marostegui how would you suggest to move forward then? I saw your comment on T109179#3773638, but not sure where that leaves this patch. Would we need to revert the switch to row based replication for s5?
I filed T181019: Consider using a single MediaWiki releases key instead of individual keys for using a release key.
Re-opening and setting as stalled. This isn't declined, it's just waiting on a new upstream upgrade.
RecentChanges is one of the core features that basically can't be unavailable. For features like this we need to have a revert mentality first (I fully admin to struggling with this too when its one of my features), and then try and debug on one of the mwdebug servers, or figure out something else. The code seems to have changed a lot since my initial version :) I'll review it a bit too.
Mon, Nov 20
@Bawolff Also, what should we do about expired keys? Tim has two keys listed, and both are already expired. Should we just replace it with his new key (what he would use if he had to make a release in the future)?
Is it OK if I put up a patch in public for this?
Sat, Nov 18
I guess we need to get the data out of the varnish web request logs, have something that parses the URLs and then aggregates the stats/maybe puts them in statsd?
Maybe @Addshore has some ideas? :)
Fri, Nov 17
mysql:wikiadmin@db1094 [centralauth]> select gu_name, gu_registration from globaluser where gu_name>'d' order by gu_name limit 10; +------------------+-----------------+ | gu_name | gu_registration | +------------------+-----------------+ | damien710 | 20130411174858 | | daniel.graziotin | 20130411204127 | | debel | 20130411211940 | | delight | 20130411211940 | | demi 84 | 20130411211941 | | deweerdt | 20130411174858 | | diba | 20130411211941 | | djam | 20130411174858 | | dlc | 20130411211941 | | dmgerman | 20130411203256 | +------------------+-----------------+ 10 rows in set (0.00 sec)
Nikerabbit explained that for TWN he has a deploy hook that restarts the jobrunner service any time any update is made to ensure that it's not running any old code.
Originally I was thinking of a timer, but another option might be what translatewiki does using runJobs.php --wait (https://phabricator.wikimedia.org/diffusion/GTWN/browse/master/puppet/modules/wiki/files/mw-jobrunner.service)
Thu, Nov 16
That's alright, it was probably caused by the readonly period for dewp.
@demon did those two patches get cherry-picked into wmf.8?
This basically means all the phan jobs aren't actually doing anything.
Based on 19:30:00 [CHECKSTYLE] No files found. Configuration error? your hunch seems correct that it's not writing to the XML file.
In Timeless if you hover over the arrows the dots show up underneath: https://www.mediawiki.org/w/index.php?diff=2608842&oldid=2001105&title=Requests_for_comment/ChangesList_formatting&useskin=timeless
Wed, Nov 15
It was also suggested on #mediawik_security that maybe instead of using individual personal keys, we should have a mediawiki release key not tied to a specific person, perhaps using some sort of secret splitting scheme.
The older keys should also be removed from https://www.mediawiki.org/keys/keys.txt