[00:05:32] Fatal error: Uncaught Exception: /var/www/wiki/mediawiki/core/extensions/Array/extension.json does not exist! in /var/www/wiki/mediawiki/core/includes/registration/ExtensionRegistry.php on line 105 [00:05:34] * Reedy blinks [00:06:30] Array to string! [01:21:25] should we pin back to 1.7.1? [01:22:23] I dunno where the regression is [01:22:32] It's hard to tell as the tests have been broken for a whiel [01:22:34] But might be worth trying [01:24:39] legoktm: https://en.wikipedia.org/wiki/Wikipedia:Bots/Noticeboard#Out_of_curiosity..._(to_all_bot_operators) last comment [01:24:59] yes it does [01:25:26] https://www.mediawiki.org/wiki/Manual:Pywikibot/OAuth/Wikimedia#Registering_your_bot_with_the_wiki_software [01:25:34] lol [01:25:35] I'll comment [01:25:38] <3 [07:02:51] Reedy: T165219 would be one way to go at it [07:02:53] T165219: Templates for owner-only OAuth consumers - https://phabricator.wikimedia.org/T165219 [07:04:09] I don't think OAuth2 ignores any magic solution for this issue, it just accepts the less secure nature of apps [07:10:34] ...provides any magic solution... [13:03:27] Reedy, legoktm: As far as I know, OAuth2 doesn't really solve the issue. https://tools.ietf.org/html/rfc6819#section-5.2.3.4, for example, says to basically do an automated owner-only thing but notes that how to do that "is currently not defined by OAuth". [14:43:45] tgr: hey! I'm about to finish https://gerrit.wikimedia.org/r/c/mediawiki/core/+/453190, should be done in about an hour [14:44:23] I'd like to get this in soon, to provide test coverage for the refactoring for mcr views. [14:44:40] it's adding tests only... do you think you might have time to review it today? [15:23:50] legoktm: thoughts on the 2 bullet points on https://phabricator.wikimedia.org/T202144 ? [15:44:40] RoanKattouw: Around? [15:44:41] <_joe_> hi, I have a question for you: is it possible that an API request for action=options format=json change=rcfilters-limit%3D500 would trigger User::saveSettings() ? [16:34:08] _joe_: yes, action=options is the API to change preferences, and you have to call saveSettings() to persist them to the DB [16:37:13] addshore: hmm [16:38:48] addshore: would it be like ->countPerWiki(...) ? [16:38:58] _joe_: is this re: https://phabricator.wikimedia.org/T202149 ? [16:39:08] legoktm: for the first or second point? [16:39:23] legoktm: no, it would maintain the same interface [16:54:02] addshore: I think the first option should be done regardless, and I don't really understand what you want to do in the secon [16:54:04] d [16:55:05] the second option would implement the same interface, and contain the main statsd service within, so -> increment could take the metric name and prefix it with some other prefix before passing it to the main service which would add the main prefix [16:55:22] but then the buffer only exists in the main service, and thus only 1 service needs to have the buffer of stats emitted [16:55:41] addshore: ohhhh, got it, just a proxy. sounds good to me [16:55:47] the first option would mean there are 2 services with 2 seperate buffers, and they have to both be emited separately [16:56:05] Yeh, PrefixingStatsDFactoryProxy or something [16:56:30] I like it :) [16:58:20] lovely, I'll do that at some point [17:16:26] Amir1: I am now [17:17:07] RoanKattouw: cool, I have a patch up for fixing master of OAuth: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/453416 [17:17:21] Cool, will look after meeting [17:17:47] Thanks! [17:43:14] RoanKattouw: Thanks. Now we can +2 this https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/452063 [17:52:51] \o/ [18:54:06] Amir1: So I was explaining the MIGRATION_* constants to someone, using the change tags code as an example, and I noticed something [18:54:25] deleteTagEverywhere() references ct_tag in ways that seem unsafe in the new schema [18:54:26] e.g. https://github.com/wikimedia/mediawiki/blob/master/includes/changetags/ChangeTags.php#L1254 [18:54:42] And this probably also needs to consider ct_tag_id: https://github.com/wikimedia/mediawiki/blob/master/includes/changetags/ChangeTags.php#L1243 [18:55:05] I don't know how far along you are with this change tag migration stuff, but I spotted these things and figured the knowledge shouldn't be lost [18:56:06] RoanKattouw: hmm, yeah. The migration still is in process (wikidata is left only and it will take for around a month) [18:56:11] Also we have this https://gerrit.wikimedia.org/r/c/mediawiki/core/+/452052 [18:56:46] and I need to make the schema changes for adding the indexes and making the ct_tag indexes non-unique [18:58:57] Oh I missed that patch in my review queue somehow, I'll review it today [18:59:10] Thanks again for taking this on! [18:59:31] Thank you for reviewing. Have you seen the impact of Special:Tags? [18:59:46] RoanKattouw: I sent an email a couple of weeks ago [18:59:59] No? I did see you adding a $wg that short-circuits Special:Tags even when the migration is half-done, but that was before my vacation [19:00:03] Oh, to wikitech-l? [19:00:31] > For example loading Special:Tags on Wikidata used to take around a minute and now it takes less than a second. English Wikipedia is down from ten seconds to less than one and so on. [19:00:33] Wow! [19:01:39] RoanKattouw: Look at the graphs [19:01:42] Holy crap those graphs [19:02:31] Yup :D [19:06:29] RoanKattouw: I was thinking of what would be the best design for the table, I think it should be split to three things: one column in recentchanges that behaves like the tag_summary table, one table for revisions and one table for logs. That would save huge amount of storage and memory and etc. but given that I'm working on it in 20% of my time, it's more of a dream [19:06:59] Basically Association Table Mapping [19:07:09] First things first IMO :) [19:07:22] Of course :D [19:07:31] That would be cool, but just this normalization is a big win [19:17:41] Yeah [19:18:44] RoanKattouw: Also, I need this in a strange way, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/450083 I want to make the patch for schema change but if it doesn't get merged first, I'll end up having lots of merge conflicts. Do you think you can review this too? [20:14:04] Amir1: +2ed (sorry for the delay, was at lunch) [20:15:08] No worries. Thank you RoanKattouw