[02:14:39] Reedy: I feel like we saw this failure before: https://integration.wikimedia.org/ci/job/mediawiki-extensions-hhvm-jessie/12844/console [02:15:59] that's the only think blocking the "move attributes out of the top level" extension.json patch [02:16:25] the core change it depends on (https://gerrit.wikimedia.org/r/#/c/327882/) isn't failing though so I'm a bit confused [15:17:10] Krinkle: remember the logstash trouble where it was showing some new log event fields as unanalyzed? I figured out the fix for that yesterday. The yellow 'recycle' button on https://logstash.wikimedia.org/app/kibana#/management/kibana/indices/logstash-* makes it look at all the mappings again. [16:02:01] Ugh, another completely changed Kibana UI. Just when I was getting used to the previous one. [16:21:06] anomie: but the new one looks like a commercial for Miami Vice! [16:21:44] Is that a feature or a bug? ;) [16:45:18] "timelion"? [16:50:22] https://www.elastic.co/blog/timelion-timeline [17:49:38] I have a random question - have we ever thought about migrating MW from PHP to Hack? [17:50:12] there's be thoughts, but nothing serious afaik [17:50:15] been* [17:50:57] I hope we think about it now that there's a dedicated team for it. [17:51:35] Niharika: making MediaWiki depend on HHVM would be a really really big change [17:52:39] bd808: Wait, doesn't it already? "Over the last six months we deployed a new technology that speeds up MediaWiki, Wikipedia’s underlying PHP-based code. HipHop Virtual Machine, or HHVM, reduces the median page-saving time for editors from about 7.5 seconds to 2.5 seconds..." [17:52:46] https://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as-fast/#How_keeping_Wikipedia_fast_meant_slowing_Wikipedia_down [17:52:57] both in the code and in our contract with our software user communities [17:53:37] I would personally like to see us move to PHP7 rather than Hack [17:56:04] Niharika: Not really. MediaWiki is written in PHP, it's just that Wikimedia happens to use HHVM's implementation of the language rather than Zend's. [17:56:40] Ah, okay. [18:51:51] Niharika: porting to Hack would be a big "screw you!" to anyone using MW on shared hosting. [18:52:02] Not that I wouldn't like generics and stuff. I'd love it! [18:54:51] DanielK_WMDE: Yeah, I agree. Even moving to PHP7 would be awesome. [19:00:06] HHVM has "all the major" PHP7 features, according to . I think our main hold-up is not wanting to break compatibility with LTS versions of various distros that are still on php5. [19:09:14] bd808: But there's like PHP7-mode for HHVM :) [19:09:23] So we could possibly start moving towards PHP7-constructs? [19:13:02] anomie: That too [19:16:07] I can't wait for the bump PHP version discussion again :P [19:16:11] I guess 1.31 will be our next LTS. At some point we should probably have the conversation whether we want to bump the PHP version requirement for that version. [19:16:55] We should also have a discussion about what we mean by LTS. [19:16:56] Isn't there an RfC about this already? :P [19:17:33] There was the RFC for raising the supported version for MW 1.27, that resulted in upping it from 5.3 to 5.5.9. T118932 [19:17:33] T118932: RfC: Raise MediaWiki's PHP version requirement and update coding standards - https://phabricator.wikimedia.org/T118932 [19:17:43] I don't know if there's any more recent RFC/. [19:28:42] Niharika: Feel free to open a new discussion :P [20:21:25] bd808: Aha, 'recycle' button it is. Okay! [20:21:30] bd808: Is this documneted somewhere? [20:21:35] (on Wikitech I mean) [20:23:48] of course not. that would be silly [20:24:21] heh [20:24:30] AaronSchulz: Can you please have a look at https://gerrit.wikimedia.org/r/#/c/350562/? [20:24:39] I'm tired of this Postgres thing coming up every release. [22:05:39] need postgres tests in jenkins [22:12:10] Timo has been poking at them a bit to get them to work on travis at least [22:13:05] Kind of. [22:13:07] Meaning, not at all. [22:13:08] https://github.com/wikimedia/mediawiki/commit/7399a3ec01e9b19003342a917ce2bf2364fe8c46 [22:13:25] https://phabricator.wikimedia.org/T75174 [22:13:36] There's a lot of failing tests. [22:13:44] But could be cascading or multiple similar symptoms [22:13:50] at least for 5 release cycles / 3 years. [22:13:58] May not be the same errors all that time though [22:20:43] Krinkle: The prefixsearch ones are kind of annoying. [22:20:50] Have I mentioned that search is absolutely useless without Cirrus? [22:20:59] Core search is abysmal. [22:21:23] Sphinx extension has been broken forever. [22:21:49] And MWSearch/lsearchd is dead and horribly incompatible with current apis. [22:52:21] Of course, it'd be nice if the people that care about the pg tests, actually attempted ot fix them, and got involved in CR [22:56:19] Reedy: weird, huh? [22:56:38] It's impossible, cannot be done [22:56:46] You just have to not be involved for months at a time, then bitch it breaks [22:57:34] Oh, and then blame everyone else for breaking your workflow [22:57:47] Because your time is limited and precious [22:57:53] So you've got to waste time fixing other things first [23:03:39] As for 350562, I recall the table name string code for PG being a fragile mess and fixing the installer required changing how those strings were generated to handle the search path correctly (specially relname queries). One extension was relying on the old behavior. I assumed the extension would just be updated to not muck trying to concatenate strings to [23:03:40] make index/table names or whatever. [23:05:48] I recall core tests being fine at the time, but that was years ago, before lots of /lib refactoring and other cleanups. [23:06:14] I see one of Timo's fixes was for a DI related bug in installer/, which isn't surprising. [23:34:15] anomie: Re: https://phabricator.wikimedia.org/T160003#3248111 I forgot that MediaWiki has pseudo-booleans, I guess.