[08:19:13] hello. see my questions in last 2 comments in https://gerrit.wikimedia.org/r/#/c/164049/ . [08:19:33] and, is this right channel? [08:21:49] qdb: you probably want either the #wikimedia-tech or #wikimedia-dev channels for general questions. For this patch you might find the best help/reviews from the #mediawiki-i18n channel. [08:22:19] this channel is mostly where the Wikimedia Foundation's Mediawiki Platform team talks with each other [08:22:49] are this my questions general questions? [08:24:01] i tended to undersand "general questions" as questions of simple usage of mediawiki. [08:24:13] it looks like you are asking about how to setup tests, so yes I would consider that a general question [08:25:15] the -tech and -dev channels have many of the same people in them. The main difference is that there are bots in -dev which report things like new patch submissions and test failures for them [08:26:01] that can make things a bit noisy for detailed conversations, but people do generally try to provide help in both channels [08:26:50] i think you should rephrase or explain it about "general questions". i have many years of experience with english via computers and internet, and i do not unerstand. [08:28:49] I suppose I mean questions that are about developing MediaWiki are welcome in the #wikimedia-tech and #wikimedia-dev channels. Questions about installing and operating MediaWiki may get better answers in the #mediawiki channel. [08:29:05] is that more clear? [08:29:06] when i entered #wikimedia-dev after some time i thought that seems it is not a channel for talking. [08:29:37] yes it is more clear [08:30:04] i mean you should edit channel topic [08:30:36] * bd808 thinks about a better way to phrase the topic [08:31:08] remove "general purpose"? [08:31:34] #wikimedia-tech is not #mediawiki-tech and its topic starts with Technical help for Wikimedia wikis, so it also seems as not right channel [08:32:11] is that better? [08:32:41] * bd808 remembers that software engineers are not always good at documentation [08:32:56] no, this is not better, community maybe users community and developers community [08:34:42] support also can be user (web admins who install meiawiki) support , and developers support (custom plugins, core patches etc) [08:36:21] though with open source it can be merged, but i understand it this way. installing mediawiki probably also can bring many problems [08:38:14] this was good: questions that are about developing MediaWiki are welcome in the #wikimedia-tech and #wikimedia-dev channels. Questions about installing and operating MediaWiki may get better answers in the #mediawiki channel [08:39:55] even if you had that channels for topics merged, you should mention them separately and link that topics to same one channel [08:40:35] in order to make it surely understandable [08:42:49] how's that? [08:47:43] it is ok. but, as i said, there is another problem, with wikimedia tech. what if somebody makes something not for wikimedia, but only for his own site or for mediawiki cms/engine, ie not for the different dictionaries and libraries and news and ... of wikimedia [08:48:53] qdb, sidenote: there are actually many many more channels related to development, see the 2 subsections of https://meta.wikimedia.org/wiki/IRC/Channels#MediaWiki_and_technical [08:49:08] * quiddity goes back to other work. :) o/ [09:11:20] seems you should better link to #wikimedia-dev , but, i think, commit reports there should be moved to a separate channel, or explanation added to not be afraid of them. [09:14:10] oh, no, wikimedia-dev is also about wikimedia! i thought its name is mediawiki-dev. so they are equally good [09:15:48] wikimedia-tech is indeed better, because it has not commit messages [09:22:40] anomie: TimStarling fixed the integration slave that was full so now your patch's tests pass [10:13:29] James_F: I think we can merge the PHP 7 patch into master today [10:34:27] Krinkle: so utfnormal... php files with the strings inline [10:34:27] UtfNormal\Validator::$utfCombiningClass = unserialize( 'a:751:{s:2:" [10:34:28] etc [10:47:22] Reedy: Really? Dumps are upgraded? [10:47:44] https://phabricator.wikimedia.org/T181029 is closd [10:47:46] *closed [10:48:14] Gosh. OK, let's do it? [10:48:28] Let me double check Ariel doesn't want us to wait a week [10:48:37] Good call. [10:51:43] Reedy: It'd be nice to announce in the demo, though. ;-) [10:51:56] If the 5.5 hosts are gone... [10:52:01] There shouldn't be any reason why we can't [10:52:08] * James_F niods. [11:03:37] James_F: CR+2 [11:04:28] Gosh. [11:04:32] Wait [11:04:51] Whut? [11:04:59] terbium [11:05:04] Gah. [11:05:12] I think we run some scripts on 5.5 [11:05:39] Of course, https://phabricator.wikimedia.org/T172165 doesn't have a relevant task as a subtask [11:06:06] Had it done I'd have shouted at people about that. [11:06:53] _joe_ might be worth finding [11:10:04] Reedy: So does that mean T172165 should be blocked by T174431 (everything over to HHVM+)? [11:10:05] T172165: Require either PHP 7.0+ or HHVM in MW 1.31 - https://phabricator.wikimedia.org/T172165 [11:10:05] T174431: Upgrade mw* servers to Debian Stretch (using HHVM) - https://phabricator.wikimedia.org/T174431 [11:38:03] James_F: As long as everything on any remaining Jessie servers are using HHVM rather than PHP5, it shouldn't *need* to block on the upgrade. [11:38:33] Whether that's actually the case or not though I don't know. [11:41:36] anomie: They're not. Terbium is running a bunch of things on php55, sadly. [11:42:03] And the surest way to "prove" whewn they're not is having them be on stretch.