[11:34:13] Md shakil Molla [21:00:04] #startmeeting RFC meeting [21:00:04] Meeting started Wed Oct 18 21:00:04 2017 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:04] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:04] The meeting name has been set to 'rfc_meeting' [21:00:22] #topic T172165 Bump PHP requirement to 7.0 in 1.31 [21:00:22] T172165: Bump PHP requirement to 7.0 in 1.31 - https://phabricator.wikimedia.org/T172165 [21:02:24] RFC author is MaxSem [21:02:43] Though I imagine a number of us can speak to it. [21:02:51] hey [21:02:58] phab commentors: Reedy Krinkle paladox ebernhar|lunch addshore anomie tgr cscott [21:03:13] \o/ [21:03:16] and a few others who may not be in this channel [21:03:23] thanks. [21:04:29] one question that came up in the committee meeting is whether this RFC implies dropping support for HHVM [21:04:44] I'm pretty sure it does [21:04:50] practically speaking [21:05:34] you did say "we can't bump the requirements until all appservers have been updated to Debian Stretch" [21:05:48] <_joe_> ok, so this is tied inextricably to moving the WMF cluster to PHP7? [21:05:52] I think hhvm is on par with 7.0? but if we migrate to php7, not sure what's the point of keeping it [21:05:56] There are the steps of "work fully in PHP7", "claim that we might not work in PHP5/HHVM", and "use PHP7 and so actively not work in PHP5". [21:06:02] <_joe_> if that's the case, we're more than one year away [21:06:11] is anybody but WMF running mediawiki+hhvm? [21:06:12] but in our previous meeting about this, mark did not want to commit to migrating to stretch before the end of the financial year [21:06:46] <_joe_> James_F: exactly my point. We can make a softer claim in this release cycle, I think [21:06:53] I think "works fully in PHP7" should be done ASAP [21:06:58] if not yet [21:07:08] we already are [21:07:19] Even for the WMF-cluster-specific edge cases? [21:07:27] <_joe_> also, migrating production to stretch is not enough for dropping hhvm support [21:07:40] ok then (I've seen some tickets but I guess those may be old or non-WMF things) [21:07:42] James_F: this we can't know for sure [21:07:53] MaxSem: … until we actually run it in production, right. [21:08:03] <_joe_> and enabling hhvm's php7 mode is not something that can be done without serious commitment either [21:08:08] T144962 is still not done. [21:08:08] T144962: Run MediaWiki tests on PHP 7 - https://phabricator.wikimedia.org/T144962 [21:09:00] I think that should be taken out of "low"then [21:09:13] <_joe_> #info < James_F> There are the steps of "work fully in PHP7", "claim that we might not work in PHP5/HHVM", and "use PHP7 and so actively not work in PHP5". [21:09:21] The alternative to this RfC, however – supporting PHP5 for MW for a long period after it's not security-supported – is a farce, though. [21:09:37] #info T144962 is still not done. [21:10:09] <_joe_> One thing is not to support officially PHP5, (option b above), another is introducing things that are actively incompatible with it [21:10:48] I think the main concern is the need to run tests against PHP 5.5 when we do security releases against MW 1.31 [21:10:53] Yes. [21:11:14] 5.5? Can't we at least go 5.6? [21:11:16] <_joe_> that has no blockers from ops [21:11:19] _joe_: we actually take this differently: stuff is linted and tested with the lowest required PHP and MW actively refuses to work with usupported versions [21:11:55] I think the choice should be 5.6 or 7, 5.5 should not be an option... [21:12:10] SMalyshev: yes, if we can't go PHP7 by the 1.31 release we should at least drop 5.5 [21:12:14] <_joe_> MaxSem: ok then dropping support for HHVM is not feasible at least until the end of 2018 [21:12:21] So the suggestion is to document that we require PHP 7, but in practice keep running on HHVM and hope that no-one writes code that breaks HHVM? [21:13:10] Sorry, require "the intersection of PHP 7 and HHVM-before-it-becomes-incompatible". [21:13:13] <_joe_> James_F: keep running all tests on HHVM [21:13:30] right, tests will need to continue running on hhvm until it's undeployed [21:13:37] anything else would be insanity [21:13:46] OK. That's probably do-able, but messy. [21:13:51] we can always require the least common denominator but in practice you would get bugs when a developer tests only on one engine [21:13:54] <_joe_> James_F: as long as it's the php5-mode hhvm, yes [21:13:56] are we still running PHP 5.5 in production? [21:14:06] TimStarling: Yes, for silver (wikitechwiki). [21:14:08] #info I think the main concern is the need to run tests against PHP 5.5 when we do security releases against MW 1.31 [21:14:09] <_joe_> TimStarling: yes [21:14:11] TimStarling: But only that, I believe. [21:14:12] can't we commit to certain version of hhvm and tell everything beyond that is your luck? [21:14:17] and our automated tests are nowhere near comprehensive [21:14:20] so that could easily be fixed before June [21:14:37] so we could make the minimum requirement for MW 1.31 be either PHP 7 or HHVM [21:14:40] <_joe_> TimStarling: we use php5 for mwscript I think [21:14:44] #info <_joe_> ok, so this is tied inextricably to moving the WMF cluster to PHP7? if that's the case, we're more than one year away [21:15:05] <_joe_> TimStarling: there is an old bug, that would be the only blocker indeed [21:15:19] <_joe_> oh, and wikitech, but that's changing soon AIUI [21:15:43] i.e. until hhvm is gone from prod, we suppport both 5.6, 7 and HHVM v.whatever.0 [21:15:55] _joe_: "php5-mode hhvm" is HHVM without the PHP7-backwards-incompatible flags set, right? [21:16:07] <_joe_> James_F: right [21:16:11] or just 7 if we can skip 5.6 by the time it's time for 1.31 release [21:16:30] <_joe_> activating it would require an effort that I think is not easily justifiable at the moment [21:16:33] another possible solution is to just keep supporting PHP 5.5 and drop this whole RFC until next year [21:16:38] <_joe_> but I can be convinced otherwise [21:16:42] MaxSem: let's fix that :) [21:16:44] SMalyshev: Why would we support PHP 5.6? REL1_31 will be supported 'til June 2021 (!), PHP 5.6 is only until Dec 2018 from Zend and April 2020 from Debian. [21:17:02] 1.31 will be supported until june 2021. I'm of the opinion that even if wmf has to run php5, and we still enforce tests on php5, the stated requirements are php7. This will ease a lot of our pain in the future backporting fixes [21:17:20] the RFC says it will be "nigh impossible" to run PHP 5.5 in 2021, which is not really true [21:17:23] TimStarling: But that means keeping running Zend 5.5 (or whatever) for CI (at least) until 2021, despite a lack of security updats. [21:17:28] DanielK_WMDE_: sure, just give me a millennia or two [21:17:30] I mean, my bar for impossibility must be a larger number of hours [21:17:37] James_F: well, that's the question. What I am trying to say, 5.5 should be out and the question should be "5.6 or 7"? [21:18:00] all you have to do is not actually change anything, CI will keep working, you don't actually need security support for CI to work [21:18:13] it's not like there is a practical security boundary between PHP code and the host it runs on [21:18:16] MaxSem: it actually saves time, in the end. but yea, it's an investment. one we have to make, rather sooner than later, imho. [21:18:20] TimStarling: I'd say "very inadvisable" but certainly possible if one really wants to... [21:18:47] <_joe_> SMalyshev: https://phabricator.wikimedia.org/T146285 is the only real blocker to move to 5.6 AIUI [21:19:20] #info REL1_31 will be supported 'til June 2021 (!), PHP 5.6 is only until Dec 2018 from Zend and April 2020 from Debian. That means keeping running Zend 5.5 (or whatever) for CI (at least) until 2021, despite a lack of security updats. [21:20:09] James_F: we don't have to run 5.5 on CI for master, though. only for the release branch. [21:20:10] <_joe_> I think dropping at least 5.5 should be feasible [21:20:11] _joe_: is there some feature blockers? or it's just some code needing to be done? I know about getopt issue, but that should be possible to work around I hope? [21:20:16] worst case, not using getopt :) [21:20:39] SMalyshev: Just lots of testing needed, I believe. [21:20:50] the minimum PHP requirement for the LTS MediaWiki version not getting security updates is nothing new [21:20:50] #info <_joe_> SMalyshev: https://phabricator.wikimedia.org/T146285 is the only real blocker to move to 5.6 AIUI [21:20:52] SMalyshev: mwscript runs a lot of code that is… precarious. :-) [21:20:57] also note phpdbg is 5.6+ [21:21:11] we have a longer LTS cycle than PHP so it always happens towards the end of the cycle [21:21:16] which means if we want CLI debugging and we want it not to be hhvm we want 5.6 :) [21:21:16] getopt can be replaced with a variety of things. We for example already have symfony/console in vendor which includes cli parsing support. [21:21:18] <_joe_> SMalyshev: only thing I'd need to check are dumps, but I'm not sure they depend on core tbh [21:21:20] And we'd want to bump PHPUnit to 6, which is PHP7+. [21:21:30] not really our job to forc the world to use up-to-date PHP, anyway [21:21:32] _joe_: apergos said that the dumps work great in PHP7. [21:21:50] _joe_: So it might make sense to jump to PHP7 for the dumps directly rather than try to switch to HHVM and back. [21:21:54] #info the minimum PHP requirement for the LTS MediaWiki version not getting security updates is nothing new. we have a longer LTS cycle than PHP so it always happens towards the end of the cycle [21:22:14] <_joe_> James_F: indeed, yes [21:22:52] tgr: forcing is a bit strong, but plenty of open source projects use their influence to push tech forward and away from out of date things. I guess off the top of my head how browsers are starting to treat non-https is an example [21:23:05] <_joe_> James_F: still, they need to be migrated, it's just part of the list of things-to-do-if-we-drop-php5.5 [21:23:18] _joe_: Totally. [21:23:47] looking at 5.6 features, I'd probably like const expressions and variadics sooner :) [21:24:17] SMalyshev: Is there any positive reason to jump only to 5.6 rather than 7.0? [21:24:23] we can move to 7.0 as soon as MW 1.32 is branched [21:24:24] _joe_: dumps do depend on core. in not-so-nice ways. [21:24:34] TimStarling: You mean 1.31? [21:24:45] 1.31 is already branched [21:24:46] James_F: not really, as far as I know. may be less BC problems but that's it [21:24:54] TimStarling: Oh, the other end of the "branching". :-) [21:25:09] I mean when the version number is updated in $wgVersion [21:25:11] it may be branched, but its not scheduled for release for 8 more months [21:25:28] TimStarling: So you propose that we reject the RfC, don't switch to 7.0 for REL1_31, but instead only for REL1_32+, and live with the LTS consequences? [21:25:38] the reason to jump to only 5.6 is because we can run it in WMF production prior to the upgrade to stretch [21:25:41] <_joe_> ok so I think dumps are not a blocker, nor is wikitech. [21:25:57] #info <_joe_> ok so I think dumps are not a blocker, nor is wikitech. [21:26:11] I think we should require 5.6 for 1.31 and 7.0 for 1.32 [21:26:20] is it easy to move production (php side) to 5.6? [21:26:30] compared to moving to 7? [21:26:44] <_joe_> SMalyshev: yes, 99% of prod is already on 5.6 [21:26:57] (5.6-equivalent HHVM.) [21:27:12] <_joe_> we just have dumps and wikitech that are still on 5.5 [21:27:16] 5.6 and 5.6-equivalent hhvm may not be the same thing though... [21:27:24] James_F: it's the actual 5.6 [21:27:27] [tstarling@tin:~]$ php5 --version [21:27:27] PHP 5.6.30-0+deb8u1 (cli) (built: Feb 8 2017 08:50:21) [21:27:39] <_joe_> James_F: what I meant is we're using hhvm and zend php 5.6 [21:27:45] TimStarling: OK, but we don't actually run anything off the app servers except the dumps and scripts from Zend. [21:28:02] TimStarling: So saying that they have 5.6 installed (but never used) isn't answering SMalyshev's question. [21:28:15] #info we can move to [PHP] 7.0 as soon as MW 1.32 is branched. the reason to jump to only [PHP] 5.6 [for MW 1.31 LTS] is because we can run [5.6] in WMF production prior to the upgrade to [debian] stretch [21:28:33] we can't migrate dumps and scripts to 7.0 prior to migration to stretch [21:28:47] <_joe_> TimStarling: we can migrate dumps to 5.6 though [21:28:56] but I assume we don't want to actually run app servers on Php 5.6? performance? [21:29:07] SMalyshev: Exactly. [21:29:15] #info we can't migrate dumps and scripts to 7.0 prior to migration to stretch <_joe_> TimStarling: we can migrate dumps to 5.6 though [21:29:20] <_joe_> SMalyshev: no, we don't want to switch production to php 5.6 [21:29:42] I understand there are reasons for not migrating everything from PHP 5.6 to HHVM already [21:29:42] <_joe_> TimStarling: when is the release of 1.31 scheduled for? [21:29:47] so the advantage of 5.6 over 7 is mostly imaginary - we can run tests and secondary services, but not mediawiki production [21:29:50] _joe_: june 2018 [21:30:09] In practice, that means April/May for core being branched. [21:30:11] #info don't want to switch production to php 5.6 [because of performance problems] [21:30:43] SMalyshev: how is that an imaginary difference? [21:31:02] the main rationale for this proposal is difficulty in running tests out to 2021 [21:31:15] it's really all about the testing [21:31:18] <_joe_> ebernhardson: thanks, that end of FY. I will still need to run this timeline by the relevant teams [21:31:27] TimStarling: well, it seems to be running on secondary services in not much different than running test stuff we already doing [21:31:27] my main rational against 5.6 until 2021 is the extra work backporting anything [21:31:48] I'd be really sad for us to still be officially supporting 5.6 for 1.31's LTS. [21:31:51] i'm certain that by 2020 we will have code that relies on php7 features. any backports are going to be annoying at best [21:31:54] production use is the real test, but we won't get that for either 5.6 or 7 by the time LTS is out [21:31:57] "Happens to work" is different. [21:32:14] <_joe_> James_F: MaxSem said before "happens to work" is not possible [21:32:20] I thought the main rationale is that we don't want to be barred from using PHP7 features until 2021? [21:32:23] _joe_: It's possible, just a kludge. [21:32:27] so the difference between 5.6 and 7 is that for 5.6 we can give it a little more testing by running it on secondary services... not sure it's a big diff? [21:32:35] and don't want to backport patches from 7 to 5.6 either [21:33:15] We ideally don't want people using huge numbers of PHP7 features anyway, as that makes backporting hard. [21:33:19] <_joe_> SMalyshev: no, the situation is what follows: if we drop php 5.6, we also drop hhvm; and we can't migrate off of hhvm easily or quickly [21:33:25] But if they're going to, we want them to start with an LTS release. [21:33:29] ebernhardson: we were going to have that problem anyway until 2019, since that is EOL for MW 1.27 [21:33:35] So 1.31 or 1.35 in June 2023. [21:33:51] SMalyshev: no, the difference is that jessie supports it, so we can use jessie for testing security releases [21:33:53] _joe_: hhvm doesn't support whole 7.0? [21:34:02] TimStarling: 12 months of work vs. 36 is a big difference. [21:34:11] TimStarling: jessie doesn't have 7.0? [21:34:12] <_joe_> SMalyshev: they're going to diverge pretty soon and we don't run hhvm in php7-mode [21:34:21] no [21:34:26] delaying progress for the sake of backports is stupid. especially since our LTSes live for 3 years [21:34:30] <_joe_> migrating to hhvm's php7-mode is neither quick not advisable IMHO [21:34:31] _joe_: if they diverge in the future, we still can use version we;re using now, can't we? [21:34:36] we have to wait for stretch to get 7.0 [21:35:18] I'm proposing delaying the switch to 7.0 until we run 7.0 in production [21:35:42] I'm proposing updating our requirements from 5.5 to 5.6 because we can run tests on 5.6 using jessie out to MW 1.31 EOL [21:35:57] hmm... no third-party builds or something for 7.0? 7.0 was released 2 years ago... [21:36:12] there are 7.0 packages for debian jessie available, we use them in CI [21:36:41] <_joe_> legoktm: I don't see how that makes a difference for production being on HHVM [21:36:54] it doesn't, I was just answering the question :) [21:36:55] to address the LTS problem, can we release 1.31 with 5.6+ minimum, but when PHP drops security support for it, we also drop support for it and require 1.31 users be using 7.0 at that time? [21:37:01] Yeah, the problem is that Ops doesn't feel they have the resources to support the HHVM–Zend transition (whatever flavour, but in practice 7.0) this fiscal year. [21:37:25] <_joe_> again, I just want HHVM-in-php5-mode to be supported until we switch production fully off of HHVM [21:37:25] so it is a given that we're running hhvm until next FY [21:37:26] legoktm: So we'll make a breaking environment change to REL1_31 after it's released? [21:37:31] legoktm: Have we ever done that before? [21:37:39] _joe_: Totally. [21:37:58] James_F: yes but it will be clearly stated ahead of time. no, it hasn't [21:38:11] ah, and it has to be in php5 mode? well then, then we'd have to keep targeting 5.6 I think, we have not much choice here [21:38:12] i think if we make a breaking environment change it should be the other way. require php7 with soft support for 5.6, and a note that 5.6 support is dropped when security updates end [21:38:16] _joe_: We could support PHP7|HHVM-5.5 with the current code, except that dumps and scripts wouldn't be able to run on Zend 5.5 or 5.6. [21:38:41] <_joe_> James_F: and that needs to be ran through ops and wmcs of course [21:38:49] James_F: I think that would take us back by increasing dependency on hhvm? [21:38:53] _joe_: Which would bring forward PHP7 demand really abruptly, which would not be cool. [21:38:55] legoktm: doesn't that defeat the purpose of having an LTS? [21:39:01] SMalyshev: No? We already have that. [21:39:11] James_F: or you mean running dumps on 7? [21:39:14] TimStarling: We could merge into REL1_31 but not master a PHP7 requirement when it's cut. [21:39:33] SMalyshev: Yeah, we'd have to run dumps and mwscript on PHP7 which is really messy. [21:39:48] (Messy because Ops said they can't support it.) [21:39:53] hmm living dangerously... [21:40:36] TimStarling: for some people it might, but overall I don't think so. if we're assuming that when 5.6 loses security support there will be publicly disclosed vulnerabilities then how much value is there in providing security updates for MW on top of an inherently insecure platform? [21:41:13] #info the situation is what follows: if we drop php 5.6, we also drop hhvm; and we can't migrate off of hhvm easily or quickly [21:42:01] I came a bit late, but did we already rule out switching HHVM into php7 mode for Wikimedia to allow for MW to require 7.0+? [21:42:28] <_joe_> legoktm: I did, yes [21:42:29] legoktm: I got an impression ops aren't happy with that [21:42:33] <_joe_> :) [21:42:39] <_joe_> ops -- me [21:42:47] heh :) [21:42:57] Note that we *do* test against Zend PHP7 for MW-core via Travis already: https://travis-ci.org/wikimedia/mediawiki/jobs/289673656 [21:43:08] <_joe_> legoktm: I think that's not a small thing to do, and it takes effort I'd rather put into moving to php7 [21:43:13] #info I came a bit late, but did we already rule out switching HHVM into php7 mode for Wikimedia to allow for MW to require 7.0+? [21:43:16] #info to address the LTS problem, can we release 1.31 with 5.6+ minimum, but when PHP drops security support for it, we also drop support for it and require 1.31 users be using 7.0 at that time? i think if we make a breaking environment change it should be the other way. require php7 with soft support for 5.6, and a note that 5.6 support is dropped when security updates end [21:43:23] #info <_joe_> legoktm: I did, yes [21:44:19] OK, so. [21:44:26] SMalyshev: my quick testing indicates that php7 mode with current hhvm immediately explodes on our code base. might be better on newer hhvm that's planned for upgrade [21:44:27] note that PHP security releases rarely affect our users, really we are saying PHP 5.6 EOL because that is a nice excuse to stop backporting things to PHP 5 syntax [21:44:41] MaxSem: ok then, that closes that option [21:45:02] I see no point in investing in it too much since it's doomed anyway [21:45:40] #info [14:44:23] note that PHP security releases rarely affect our users, really we are saying PHP 5.6 EOL because that is a nice excuse to stop backporting things to PHP 5 syntax [21:45:50] so that would be December 2018, we would update the version requirement in a minor release at that point [21:45:57] #info SMalyshev: my quick testing indicates that php7 mode with current hhvm immediately explodes on our code base. might be better on newer hhvm that's planned for upgrade [21:46:32] Assuming we've managed to get to PHP7 in production by then. [21:46:54] _joe_: if wikitech/dumps are still on 5.5, will they be 5.6 by the time 1.31 is released? [21:47:08] I'm not ready to agree to that idea (change requirement in a minor release) in this meeting [21:47:38] legoktm: The blocker to wikitech (get rid of OSM) is in the hands of WMCS, but going well, I hear [21:47:41] <_joe_> legoktm: that needs to be cleared with the teams [21:47:42] I'm happy to agree to a bump from 5.5 to 5.6 right now if anyone is interested in that [21:47:51] and we can keep discussing 5.6 -> 7.0 later [21:47:52] legoktm: For dumps that'd be apergos's call. [21:48:14] <_joe_> but if there is consensus here, I can poke the relevant people and have them comment on the phab ticket [21:48:20] I think bumping to 5.6 is the minimum we should do in any case [21:48:25] TimStarling: 5.6 is what I initially proposed :} [21:48:28] TimStarling: Announce for final call with "1.31 will ship with 5.6 and maybe 7.0 later; 1.32 will be 7.0"? [21:49:04] And leave the 'maybe' for a follow-up discussion in six months' time when we know more? [21:49:25] James_F: that sounds good [21:49:41] yeah, we can have a follow-up discussion any time before the 1.31.0 release [21:49:43] OK. [21:49:47] 5.6 sounds good to me, we just need to make sure Wikimedia is off of 5.5 by the time 1.31 release comes around [21:50:21] (We can't actually make the code change to 5.6 yet, BTW. We'd need Ops to upgrade Zend from 5.5 to 5.6 first or wikitech/the dumps/mwscript would just stop working.) [21:50:26] realistically, by April - we'll need a moonth to convert the code base [21:50:30] Even if it's "easy". [21:51:10] let's say that the proposal is 5.5 -> 5.6, as soon as practical (not waiting until June), and we encourage ops to finish migrating things from 5.5 to 5.6 [21:51:24] and make a last call announcement for that [21:51:24] WFM. [21:51:28] <_joe_> +1 [21:51:36] But no mention of 7.0? [21:51:41] right [21:51:46] not in the last call anyway [21:51:46] Hmm. [21:51:56] and also we should keep "runnable on 7" (CI, etc.) with the intent that once 1.31 is released we jump to 7.0? [21:51:57] 7.0 WILL ALWAYS BE IN OUR HEARTS [21:52:11] or as early as ops can allow us? [21:54:04] SMalyshev: it's a separate issue, but yes we are working on PHP 7 in CI, maybe legoktm has an update on that [21:54:11] I'd be pretty dissatisfied with that, but the lack of others commenting makes me think I'm in the minority. [21:54:30] yes, surely, separate but related :) [21:54:52] #info 1.31 will ship with 5.6 and maybe 7.0 later; 1.32 will be 7.0? And leave the 'maybe' for a follow-up discussion in six months' time when we know more the proposal is 5.5 -> 5.6, as soon as practical (not waiting until June), and we encourage ops to finish migrating things from 5.5 to 5.6 [21:55:06] SMalyshev: last week I got all of our composer libraries running tests on php7, all pass their test suites except for one. [21:55:16] er, two weeks ago I think. [21:55:18] sooo.... when we can start using 5.6 syntax in the code finally? [21:55:28] legoktm: cool! [21:56:24] SMalyshev: we will have a last call period of 2 weeks, then a gerrit change to update the requirement, then that gerrit change will potentially be blocked on ops, we'll see [21:56:41] ok [21:56:53] once the commit is merged, you can go ahead and use 5.6 syntax [21:57:56] Well, as long as it passes CI. ;-) [21:58:37] hm, we'll also need to update CI for php5.6, might as well start on that now. [21:59:25] #agreed Entering last call: update the MW version requirement in master to 5.6/HHVM, as soon as practical [21:59:25] Yeah, legoktm, if you want any assistance just shout. [22:00:25] TimStarling: So T172165 will be put on hold, and we'll re-discuss it in ~6 months? [22:00:25] T172165: Bump PHP requirement to 7.0 in 1.31 - https://phabricator.wikimedia.org/T172165 [22:00:57] (And probably re-titled to be 1.32 or whatever.) [22:01:46] MaxSem: do you want to handle updating phabricator? [22:02:01] sure [22:03:06] just to be clear - this does include the 1.31 branch, right? [22:03:13] DanielK_WMDE_: Yes. [22:03:15] TimStarling: do we need a ticket for 5.6 upgrade? [22:03:21] MaxSem: Make a new one. [22:03:24] yes [22:03:42] MaxSem: Wait, are you going to re-use T172165 for the 5.6 RfC decision? [22:03:57] MaxSem: 'Cos if so it's going to change almost all the blockers. [22:03:59] meeting time is up [22:04:13] no I understood that I was asked to retitle the RFC as 7.0 in 1.32? [22:04:46] no, 5.6 in 1.31, for now, so that can go on last call [22:04:49] changing the phabricator stuff can be at MaxSem's discretion in discussion with James_F etc. [22:05:01] #endmeeting [22:05:02] Meeting ended Wed Oct 18 22:05:01 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:05:02] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.html [22:05:02] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.txt [22:05:02] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.wiki [22:05:02] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-10-18-21.00.log.html [22:05:03] OK. [22:05:06] Thanks everyone. [22:05:51] MaxSem: well, doesn't matter, really. two tickets. the one for 5.6 goes on last call [22:20:14] James_F, DanielK_WMDE_, TimStarling: https://phabricator.wikimedia.org/T178538