[03:16:42] legoktm: I thought you were dropping PHP 5 support from timestamp because it needed some PHP 7 feature, but you are proposing to drop it from RemexHtml proactively? [03:16:50] or for CI convenience? [03:19:48] TimStarling: being proactive - the new codesniffer version is 7.0+ already, and the rest of our tooling is also moving in that direction. CI will need to support PHP 5 for a year or two still, so it's not a huge burden. I can restore PHP 5.5 tests if you want me to though, it's pretty simple [03:21:56] and this would become 2.0.0? I assume requiring PHP 7 is a breaking change [03:22:03] yes [03:22:58] ok, I guess CI is a good enough reason [03:47:21] hmm, the packagist service hook doesn't seem to be working [03:47:25] https://packagist.org/packages/wikimedia/remex-html is stuck at 1.0.3 [03:47:38] I even tried triggering it manually [03:48:34] * legoktm will debug after dinner [06:07:54] TimStarling: is ParserDiffTest still useful to keep around? [06:08:10] that seems to be only usecase I can find of having $wgParserConf['class'] not be 'Parser' [06:08:38] probably not, but it seems sad to lose that little bit of theoretical abstraction [06:09:05] I used to tell the parsing team folks that the parser is already pluggable because we have $wgParserConf['class'] [06:09:31] I'm asking because I realized that we didn't implement that ability in ParserFactory [06:10:27] seems like it would be nice to have in the lead-up to Parsoid integration [06:12:35] ok...we'll need a proper interface then [06:12:46] which brings us back to a parser API :) [06:13:39] I've also seen a decent amount of `new Parser( [ 'class' => 'Parser' ] )` which is amusing [11:29:01] what's the procedure for setting up a new ssh key for production shell access? [11:29:16] I forgot my passphrase, since I never use it >_< [11:37:47] tgr[m]: do you mind if I take on T174035? [11:38:19] T174035: Allow the view action to show multiple slots [MCR] - https://phabricator.wikimedia.org/T174035 [11:40:02] DanielK_WMDE: not at all, thanks! [11:41:13] I still have some non-MCR stuff for today so if I get the fix for T201218 up I'm already happy [11:41:13] T201218: Viewing page's first revision via diff gives error - https://phabricator.wikimedia.org/T201218 [11:43:55] tgr: ok, i'll stare at the phase 3 board a bit, then I'll poke at the view stuff [14:28:28] TimStarling, legoktm $wgParserConf['class'] in of it self doesn't make the parser pluggable ... you need an API that is implementable in the pluggable parser. [14:45:45] TimStarling, legoktm did a new version of Remex get released? [14:46:23] subbu: legoktm released version 2 to drop older PHP support [14:46:23] https://github.com/wikimedia/remex-html/compare/1.0.3...2.0.0 [14:46:57] Reedy, ok, thx. [14:47:28] I don't think he's bumped it in mw core yet [14:47:36] k [14:47:59] But I guess he will be planning on doing so in the near future [16:52:26] tgr[m]: It's... ALIVE! https://phabricator.wikimedia.org/F24939656 [16:53:23] \o/ [19:03:39] Krinkle: Do you think you can review this: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/452739 ? [19:04:07] I'm sorry, I should backport this and deploy it, I'm not sure if it's UBN! or not though [19:05:11] Looks like it can consistently trigger a fatal from a simple user action, which, if recently regressed, is usually UBN. [19:05:13] I can review it. [19:05:21] Can you reference a commit that introduced it? [19:10:51] Krinkle: let me find it [19:11:06] Ia61b9878595dedd2725148e1078063bf1f127d2a [19:11:19] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434814 [19:11:34] Krinkle: the only good thing is that this type of user action happens pretty rare [19:12:39] You may wanna go to the cinema and come back to deploy it. Current rate of Jenkins.. been "deploying" a change for 45min now. [19:15:06] Wow [19:16:17] I probably can watch a Tarantino's movie (The Hateful Eight was three hours and 7 minutes) [20:44:53] subbu, TimStarling: https://gerrit.wikimedia.org/r/q/topic:remex-2.0.0 [20:47:39] legoktm, should i +2 that? i just +1ed right now. [20:49:29] subbu: sure, the vendor and core patches just need to be +2'd at the same time, (and then Tim's patch whenever) [20:53:42] Technically you should +2 the core patch and then the vendor one. [20:54:15] (That way Jenkins ensures that they're immediately one after the other.) [20:54:18] ya .. i was wondering what 'at the same time' meant. :) [20:55:02] If you +2 the vendor one and then the core one, there's a risk that you'll end up with [vendor][foo][core] as the stack, in which foo will fail (wrongly) and then reset the stack. [20:55:19] At a time when core is taking two hours to merge, resetting the stack is Not Cool™. [20:55:53] * subbu will let you guys +2 it .. have to get ready for a meeting [21:43:54] Krinkle: there's no easy revert. I'll spend some time looking into it today [22:02:20] are there any conventions when creating interfaces on MW ? [22:03:35] PHP interfaces? I think it's just if you need one, create one [22:04:06] yes, PHP interfaces [22:04:09] any naming conventions? [22:04:24] I see that we use `I` Prefix in some places [22:04:53] that and I think a few places have an Interface suffix [22:05:34] I'll rather use the suffix [22:10:47] The third option is no prefix/suffix, and to instead have the class implementation be specific about its decisions. [22:11:05] E.g. interface Foo and class BarFoo [22:11:58] Which is sometimes difficult to name, but given there is already talk of an interface, there presumably can be multiple implementations, which is a good reason not to not give the default implementation a too-generic name, either. [22:12:32] AbstractImplementationFactoryInterface however is probably too long a suffix. :-) [22:14:14] I see [22:14:26] technically I can get away without the prefix/sufix I think [22:14:44] so if that's preferred I can do that [22:16:18] this is not written down anywhere tho, it will be nice to have it as part of the coding conventions so new code is a bit more consistent [22:18:01] Yeah... We should really decide and document something for this [22:36:49] Reedy: You mean, actually have architectural standards?! Never. ;-( [23:25:01] legoktm: Is the plan for T160814 to do the exact same as for wgContLang? If so, should I Just Do It? [23:25:02] T160814: Deprecate $wgLang - https://phabricator.wikimedia.org/T160814 [23:34:45] I don't think it needs to be added to MWServices, if that's what you mean. $wgLang is user specific, so having it in RequestContext already should be good enough [23:35:00] I think we can go ahead and just deprecate it [23:35:54] Right. [23:37:34] I'm staring at $wgMemc right now, and found out we have two functions that do the exact same thing [23:43:22] anomie_: Looking at api-feature-usage in context of T201971, and noticed that the top one (action=query&prop=revisions&!rvslots) accounts for 45M rows per day, the majority of which comes from WMF itself (Parsoid, ChangeProp and MobileContentService). Is that deprecation working as expected? if so, perhaps it's a bit too soon? [23:43:23] T201971: Shorten logstash retention temporarily - https://phabricator.wikimedia.org/T201971 [23:44:29] he's still on vacation for a few more days [23:45:01] it was announced in https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2018-August/000140.html [23:46:13] https://en.wikipedia.org/wiki/Special:ApiFeatureUsage?wpagent=Parsoid&wpstartdate=2018-07-15&wpenddate=2018-08-14 [23:59:51] TimStarling: I'm making a patch for https://phabricator.wikimedia.org/T193565 btw