[09:18:44] ^demon|away: https://gerrit.wikimedia.org/r/#/c/193385/ [13:19:43] 6MediaWiki-Core-Team, 6Multimedia, 6Parsoid-Team, 6Release-Engineering, and 3 others: Prepare Platform/Ops April 2015 quarterly review presentation - https://phabricator.wikimedia.org/T91803#1156644 (10Qgil) [13:20:37] 6MediaWiki-Core-Team, 6Multimedia, 6Parsoid-Team, 6Release-Engineering, and 3 others: Prepare Platform/Ops April 2015 quarterly review presentation - https://phabricator.wikimedia.org/T91803#1156650 (10Qgil) Instead of "Blocks" should be "Blocked by", right? But we don't need all these notifications, so le... [14:32:34] legoktm: In the skin, at the request of the ParserOutput... You'll run into that sort of problem with Title's URL-generating methods too, I believe. [14:59:10] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Revisit GlobalUserMerge after testing - https://phabricator.wikimedia.org/T961#1156900 (10bd808) a:3brion [15:04:28] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization: Code review CentralAuth's GlobalUserMerge and related UserMerge code before SUL finalization mass usage - https://phabricator.wikimedia.org/T961#1156910 (10bd808) [15:31:07] 6MediaWiki-Core-Team, 6Multimedia, 6Parsoid-Team, 6Release-Engineering, and 3 others: Prepare Platform/Ops April 2015 quarterly review presentation - https://phabricator.wikimedia.org/T91803#1156972 (10bd808) >>! In T91803#1156650, @Qgil wrote: > Instead of "Blocks" should be "Blocked by", right? But we do... [15:58:17] 6MediaWiki-Core-Team, 15User-Bd808-Test: Setup communication infrastructure for new Platform teams - https://phabricator.wikimedia.org/T93904#1157096 (10ksmith) Are we leaving IRC channels as they are? [16:02:48] 6MediaWiki-Core-Team, 15User-Bd808-Test: Setup communication infrastructure for new Platform teams - https://phabricator.wikimedia.org/T93904#1157100 (10bd808) >>! In T93904#1157096, @ksmith wrote: > Are we leaving IRC channels as they are? I don't see an immediate need to create more channels. If a team deci... [16:04:26] robla: that box that you pick up a piece of and talk into that sits on your desk was making a funny noise [16:14:38] ^d: https://gerrit.wikimedia.org/r/#/c/200059/ [16:16:16] 6MediaWiki-Core-Team, 15User-Bd808-Test: Setup communication infrastructure for new Platform teams - https://phabricator.wikimedia.org/T93904#1157118 (10Legoktm) For the record, both `#mediawiki-api` and `#wikimedia-api` have existed for years, but were both empty when I just joined them. I would much rather w... [16:22:26] A rename might work :) [16:23:03] But to what? #wikimedia-platform? [16:24:22] #wikimedia-catchall [16:24:23] We merged with multimedia and then split into api, availability, performance, search and security [16:25:13] inb4 #wikimedia_security [16:25:38] greg-g: I think we call that #wikimedia-dev :P [16:25:50] legoktm: that's the other solution :) [16:26:05] The bot traffic there is crushing [16:26:32] yeah...it's gotten worse [16:26:54] * bd808 sort of wants a "this is just for bots" channel and a "this is mostly for humans" channel [16:27:22] I want to watch the bot feed and ping on things but I don't want to try and talk around them [16:27:39] meh whatever. it will all work out [16:27:39] #mediawiki-feed is the "this is just for bots" channel [16:27:59] But then the bots poop in other places too [16:28:21] and my client isn't smart about silence in only some channels I don't think [16:28:35] I might be wrong about that though [16:29:05] ^d: https://gerrit.wikimedia.org/r/#/c/199820/ [16:29:18] * aude is in way too many channels :P [16:29:20] doesn't need more [16:30:00] <^d> aspiecat: Oh wow yeah [16:30:02] <^d> good catch [16:30:25] * greg-g is in 29, vast majority #wikimedia-* [16:30:49] yeah, 22 are WMF/MW related [16:30:53] <^d> 19 right now. I try to keep it <20 [16:31:13] I never look at more than 6 unless I'm pinged [16:31:21] ^d: still would like to get someone to look at https://gerrit.wikimedia.org/r/#/c/197978/ [16:31:25] I'm "only" in 22 MW/WMF channels [16:31:33] and 4-5 others [16:32:04] <^d> I remember when we had like 3 tech channels [16:32:07] <^d> And we LIKED it [16:32:14] I lost the IRC battle a long time ago, 70 channels [16:32:34] ^d: and 3 employees and ... [16:32:44] <^d> Simpler times! [16:32:53] let's become a startup! [16:33:13] MikiWedia Foundation! [16:33:27] fire everyone who won't move to $NEW_HOT_LOCATION and start all over [16:34:07] Wiki Tech Foundation! [16:34:59] bd808: #wikimedia-platform was exactly going to be my proposal :) [16:35:28] I'd be fine with that [16:35:48] Drastic [16:38:02] * bd808 just made gmail sad by tagging all messages from gerrit [16:51:07] Fun logging stuff for people to review -- https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branch:master+topic:logging,n,z [17:07:23] 6MediaWiki-Core-Team, 6Phabricator, 10Security-Reviews: Install PHPExcel so I can export reports - https://phabricator.wikimedia.org/T152#1157306 (10Christopher) Exporting stuff can be useful. Check out https://phab08.wmflabs.org/project/sprint/burn/8/ for the test prototype of a CSV exporter of sprint pr... [17:43:10] 6MediaWiki-Core-Team, 10Flow: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1157414 (10EBernhardson) [17:43:21] 6MediaWiki-Core-Team, 10Flow: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1157415 (10EBernhardson) p:5Normal>3High [17:43:35] 6MediaWiki-Core-Team, 6Collaboration-Team, 10Flow: Avoid use of merge() in Flow caches - https://phabricator.wikimedia.org/T94029#1157417 (10EBernhardson) [18:10:54] 6MediaWiki-Core-Team, 10MediaWiki-Email, 7I18n: Long article URLs in watchlist notification email body due to encoding for non-ASCII scripts - https://phabricator.wikimedia.org/T72245#1157506 (10Mattflaschen) Adding #MediaWiki-Core-Team for their consideration. [19:07:53] 6MediaWiki-Core-Team, 6Release-Engineering, 6WMF-Legal, 6operations, 7Documentation: Sphinx generated documentation should state license in footer - https://phabricator.wikimedia.org/T94000#1157746 (10Mattflaschen) [19:10:51] 6MediaWiki-Core-Team, 6Release-Engineering, 6WMF-Legal, 6operations, 7Documentation: Sphinx generated documentation should state license in footer - https://phabricator.wikimedia.org/T94000#1157755 (10greg) FYI: Just putting: ``` (C) Wikimedia Foundation Licensed under $whatever_license, see LICENSE for... [19:29:33] legoktm: any chance to look at those touch() patches? [20:00:19] aspiecat: on a normal login request, since that's POST and reading the password hash out of master, isn't it ok to do a db write there? [21:14:31] I could use a sanity check on https://phabricator.wikimedia.org/T93994#1158010, if anyone is interested in looking. [21:22:43] ^d: you are probably busy, but just checking whether you saw my comments on the Http::get thing and whether you have any thoughts? [21:23:03] <^d> I did catch them, I didn't have any immediate thoughts as to how to deal with it [21:23:13] ok [21:23:24] <^d> I know it's not really b/c for callers (I tried to keep b/c as much as I could in the function definition though to support both callers) [21:24:18] simple but dirty is to add release-notes and use Http::request if multi-version compatibility is needed [21:25:09] <^d> Yeah, I can definitely do release notes [21:53:02] anomie: anything else on https://gerrit.wikimedia.org/r/#/c/200027/ ? [21:56:44] AaronS: Re ApiVisualEditor, should it still deduplicate and ping limit though? [21:57:25] I don't think so [21:57:35] I think I responded in PS1 [21:58:32] It sounded like you responded about ignore_user_abort(), but not clearly about deduplication or ping limiting. [21:59:02] If it shouldn't deduplicate or ping limit then it looks good. If it should, then that probably needs doing. [21:59:33] * anomie is out [22:00:22] yeah, it could probably do some ping limiting too, maybe [22:01:12] ori: I guess that leaves https://gerrit.wikimedia.org/r/#/c/200027/ to you [22:33:04] ^d: https://gerrit.wikimedia.org/r/#/c/199826/1 if you are daring [22:33:54] <^d> At 4pm on a friday? nowai :p [22:34:47] AaronS: Do you need any help from me/us/whomever on T90040? [22:39:13] * AaronS wishes stuff was documented better, really just prologue comments and broken up methods would suffice, ah well [22:39:17] * AaronS wades [22:39:50] James_F: I suppose paction=serializeforcache is the one used during edit summary typing [22:40:10] I'm wondering if that should just stash alone or if a secondary param should be needed [22:41:21] AaronS: Maybe? [22:41:31] AaronS: Krenair or Roan can help. [22:41:52] * James_F summons. [22:42:16] at least the JS expains stuff better than the PHP [22:42:18] * AaronS looks at ve.init.mw.Target.prototype.prepareCacheKey [22:42:26] shouldn't be too hard to change [22:42:56] Sorry yeah the PHP code is pretty poorly documented [22:43:12] Basically what the JS expects is to submit HTML to the API module, and get a 'cachekey' back [22:43:35] Then later it can use that 'cachekey' to request the wikitext, or request a diff between the current wikitext and the new wikitext, or cause the wikitext to be saved [22:43:42] This is so we don't needlessly transmit the wikitext to the client [22:51:48] ( AaronS ---^^ ) [22:52:05] yes, I saw :) [22:52:44] OK :) [22:55:49] RoanKattouw: so will all serializeforcache callers be thinking about saving eventually or is there a use case that just cares about html <--> wikitext stuff [22:55:51] ? [22:58:38] It is possible for the user to see the diff, go "ZOMG" and go back to the editor to change things [22:58:59] AaronS: serializeforcache callers will probably *intend* to save, but once they see the diff they might change their mind [22:59:30] sure, I don't mean "saving this no matter what", but it's assumed to be the likely outcome [22:59:42] of course edit stashes can be discarded/ignored [23:01:26] Yea [23:16:51] RoanKattouw: we can assume CONTENT_MODEL_WIKITEXT with postHTML results right? [23:22:58] Ahm... [23:23:02] Maaaybe [23:23:06] I'm not sure how Flow works [23:23:27] Ask superm401 to be sure but I think the answer is probably yes [23:26:20] I see that hardcoded with some bits [23:45:48] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Value representation - https://phabricator.wikimedia.org/T90123#1158924 (10Smalyshev) This can be resolved now, right? [23:47:26] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Value representation - https://phabricator.wikimedia.org/T90123#1158925 (10JanZerebecki) 5Open>3Resolved [23:56:45] AaronS: any idea what the memcached key "enwiktionary:lag_times:db1024:lock" belongs to? [23:57:23] It was occurring with other keys as well [23:58:01] like enwiki:revisiontext:textid:650393323 [23:58:13] and svwiki:messages:sv:lock [23:58:22] the nutcracker services have freaked out before [23:58:48] ori: about? Krenair is seeing a flurry of nutcracker/memcached errors [23:59:22] but that lag_times key is made by MW core's LoadMonitorMySQL [23:59:53] don't know if I'd call it a flurry