[18:44:31] matt_flaschen: what was the task you mentioned that android might be interested in? cc dbrant|brb niedzielski [18:45:35] dr0ptp4kt, https://phabricator.wikimedia.org/T121936 . Every project name in every language. [20:15:31] dbrant: niedzielski see above from matt_flaschen . cc also bgerstle and JoshM [20:29:08] dr0ptp4kt matt_flaschen dbrant: if i understand correctly, we already generate these periodically for inclusion in the app [20:29:24] dr0ptp4kt matt_flaschen dbrant: at least for our app language list [20:35:48] niedzielski-eat, can you post to the bug (https://phabricator.wikimedia.org/T121936) saying what these messages are and whereyou get them? If it's only a subset, we will probably still go ahead though, since we want to have all of them once and for all. /cc dr0ptp4kt [20:57:30] matt_flaschen will do [20:58:39] Thanks [22:01:08] #startmeeting RFC meeting [22:01:09] Meeting started Wed Jan 27 22:01:08 2016 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:01:09] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:01:09] The meeting name has been set to 'rfc_meeting' [22:01:13] o/ [22:01:34] #topic Raise MediaWiki's PHP version requirement | RFC meeting | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:02:08] #link https://phabricator.wikimedia.org/T118932 [22:04:21] TimStarling: can you recap the options that are up for discussion? [22:04:55] at this stage I think we are just going to mark the RFC as approved, and discuss consequences [22:05:08] works for me [22:05:19] \o/ [22:06:00] I assume that means we will raise the minimum requirement to 5.5.?? [22:06:04] Approved at what level? 5.5? [22:06:13] that's my understanding [22:06:18] yeah, to 5.5 [22:06:35] what about traits? [22:06:37] to recap the process we have followed so far... [22:06:51] we had an RFC, then we had a first IRC meeting [22:07:23] the IRC meeting was populated mostly by developers and there were no objections, we agreed to go to 5.5 and all participants were overjoyed [22:07:44] then a number of users said that we are really screwing them over with this decision, and maybe we should have thought of them first [22:07:46] 5.5.9 is the suggested versions as it co-incides with 14.04 [22:08:06] so I reopened the RFC for review [22:08:19] I think the main concern was that a large portion of users said that they would have trouble upgrading to PHP 5.5. We came to the conclusion that while this my be the case, it's not going to get better by waiting longer. At some point, people will have to face the trouble of upgrading. [22:08:20] Reedy: thanks. I was wating to ask if we had picked the .x version yet or had ideas [22:08:37] I ran a little survey, and about 50 people responded [22:09:30] the survey confirmed the objections, in that yes, there are a lot of people running 5.3 who cannot easily upgrade [22:09:32] requiring precisely 5.5.9+ would probably be too much as there are distros other than Debian/Ubuntu [22:09:53] just some 5.5 version that's stable enough [22:10:09] however, this fact has not changed the mind of the people who initially supported the shift to 5.5 [22:10:35] MaxSem: 5.5 is upto .29 now.. so .9 is relatively low :P [22:11:03] next version released next week is 5.5.32 [22:11:14] Incidentally I got an email from 1and1 yesterday saying that PHP <5.5 was going to cost me $8/month starting next month if I wanted to keep using it. That's evidence that at least one shared hosting provider in the universe wants to get rid of old PHP versions too. [22:11:18] security support for 5.5. will stop in 5 month, so in effect we will require the latest unsupported php version [22:11:29] various arguments were made as to why it should not change the decision: for example end of security support for 5.3, and the proposition that waiting won't actually make upgrading to 5.5+ any easier [22:11:52] I just found a list of linux distros with the PHP versions they ship with: http://www.sasaprolic.com/2013/02/list-of-current-php-version-in-major.html [22:11:52] bd808: nice! [22:12:06] bd808 that's possibly the first time i've heard something positive about 1and1 ! :D [22:12:07] it says it's from 2013, but it seems to list releases from 2015 too [22:12:17] bd808: no wonder, they probably need to backport security fixes [22:12:40] It's missing CentOS 7 etc [22:12:59] Reedy: note that the debian/ubuntu version probably has a ton of backported patches on top of upstream .9 [22:13:01] Reedy: See RHEL [22:13:01] OTOH 5.6 recently got extended security support, and backporting from 5.5 to 5.6 won't be super-hard if necessary [22:13:09] I was very surprised to find that 1and1 also has PHP7 available today [22:13:34] hmm... 1and1 sucks much less than I tought apparently :) [22:13:42] We still have to choose a number [22:13:52] this being an unusual case of an intractable split in our community between developers and users, there were questions of process and control [22:14:17] And picking one that wouldn't run on WMF servers would be counterproductive for WMF (ie if we picked > 5.5.9) [22:14:23] SMalyshev now don't jump too quick to that conclusion... [22:14:40] just because they're doing ONE thing right doesn't mean they don't suck :p [22:14:43] TimStarling: I'm curious how much survey bias came into this. Were those 50 responses representative, or just the people who'd been chiming in mostly re: keeping 5.3 and such? [22:15:29] If you use wikiapiary etc, they don't seem to be representative (with some WMF skew) [22:15:37] Obviously, that's only public wikis etc [22:15:39] ostriches: well, you can read my mediawiki-l call for participation, I tried to avoid emphasis on the 5.5 discussion [22:15:46] ostriches: yea, good point. people concerned about upgrading are much more likely to respond to such a survey [22:15:56] TimStarling: calling it an "intractable split in our community between developers and users" seems a little melodramatic, no? [22:15:59] Reedy: I agree but we should just not say which patch level of 5.5 we support as we might not be testing on the upstream variant. unless we actuall make a pure upstream build for our CI. [22:16:11] jzerebecki: Well, we do currently :) [22:16:36] We picked 5.3.3 as .1/.2 have some show stoppers [22:16:40] so the process options available to us were essentially: committee decision or vote [22:17:00] (joining late) [22:17:10] TimStarling: I know, but what DanielK_WMDE said...the discussion had clearly been floating around already and I'm just thinking there's probably some bias in who decided to respond [22:17:13] Reedy < 5.3.6 did, especially with bcrypt [22:17:20] TimStarling: So we can have a vote on which we use? Haha [22:17:30] in the absence of people really motivated to decide on voter qualifications and set up voting software, we went with a committee decision [22:17:39] 5.5.9 has a bug with IPTC as we found too... [22:17:44] #link https://www.mediawiki.org/wiki/Consensus this decision has caused me to do a lot of thinking about this [22:18:01] this being more consistent with the Rust RFC process we are heading towards anyway [22:18:07] Reedy: are we using IPTC in wikimedia? [22:18:18] y [22:18:29] SMalyshev: it's that one you fixed upstream for me [22:18:33] I presume as it was a GSoC project originally, it was written with wikimedia in mind [22:18:44] Can we allow traits for ApiMessage this time around? [22:18:52] bd808: ah. My memory is bad :) [22:18:59] heh [22:19:34] I think that's the bug Reedy means anyway [22:19:37] Yeah [22:19:51] I was asking because there's a buffer overflow in one of the IPTC functions that we'll be fixing in the next 5.5+... it's not trivial to trigger but it's there [22:19:51] so what is it that we are to discuss in this particular meeting? [22:19:51] Just "reappeared" from legoktm adding 5.5.9 stuff to Jenkins [22:20:11] on zend-php of course, hhvm may be different [22:20:33] ori: Probably a good thing to know, as we've already got sidetracked :) [22:20:52] ori: we're discussing the ArchCom's decision to approve T118932, and what needs to happen now [22:21:26] Link: https://phabricator.wikimedia.org/T118932 [22:22:37] TimStarling: where would you like this conversation to go? ("hell" is not an option ;)) [22:23:20] ori: we don't really have an agenda [22:23:55] so feel free to raise points for discussion [22:23:58] one thing we could discuss is whether we should organize some kind of tech support clinic hours for people who would like to upgrade but might need help [22:24:24] * gwicke volunteers to provide mediawiki-containers install support [22:24:25] seems like a nice thing to do, but may also set expectations that we can fix things which we actually can't [22:24:40] Yeah, scope creep seems potentially huge there [22:24:58] We should probably bump master soon so it has plenty of time to bake before 1.27 branching. [22:25:27] TimStarling: Can we allow traits for ApiMessage this time around, per later comments on T118932? [22:26:03] another thing that Reedy is bringing up is whether 5.5.9 should be the minimum version, or if it should be 5.5.[0-8] [22:26:09] it's my personal view that keeping support for versions that are unsupported is actually counterproductive for users of mediawiki ; let alone security flaws in unsupported versions, old versions don't offer some of the new stuff new versions have to offer - better support for namespaces, generators, to name only them [22:26:25] ostriches: #action ? [22:26:28] Supporting them is hard [22:26:30] anomie: is there an ApiMessage RFC? I don't see much about it on T118932 [22:26:55] No offence meant to ostriches, but the last set of security releases showed the difficult of the backports for older versions [22:26:56] ori: If everyone thinks that's right :) [22:27:21] #action gwicke / services to improve upgrade documentation for people migrating from shared hosting to mediawiki-containers [22:27:32] TimStarling: https://github.com/wikimedia/mediawiki/blob/master/includes/api/ApiMessage.php#L70 has been there since the code was written, but due to timezones I didn't make the first meeting deciding this to advocate for it when traits were being limited. [22:27:42] gwicke: 👍 [22:27:59] that shows as a square for me [22:28:14] robla: +1 to 5.5.9 as min, but I'd like to hear from others. [22:28:32] anomie: it'll be a small patch, right? [22:28:38] Alphos: I have the same response to people who ask me to assist them with installing extensions I maintain on PHP 5.3. Always met with, "Why are you running an insecure version of PHP?" [22:28:41] gwicke is a square! ;-) (seriously, thanks for volunteering that) [22:28:45] TimStarling: can you summarize where we are regarding traits? the description of the RFC says forbidden, I don't think that reflects the last IRC session. [22:29:10] I don't see any objections to 5.5.9 [22:29:17] speaking of trits, here's what I promised to draft last meeting: https://gerrit.wikimedia.org/r/#/c/265554/ [22:29:24] yeah, I didn't write that task description [22:29:30] err, wrong link [22:29:41] ori: The only real question is whether we pick a (slightly) lower version to include other OS' decisions [22:29:45] Trela when dev'ing, i'm very clear i will not support things installed on unsupported versions of php ; if they want my stuff, they'll probably have to run 5.5 - most of my stuff works on 5.4, but not all of it [22:29:46] i think the tenor regarding traits was "discouraged, allow careful experiments" [22:30:09] (and i really am unkeen to work around some of the limitations) [22:30:11] https://gerrit.wikimedia.org/r/#/c/255484/ <-- Make ContextSource traitable [22:30:25] DanielK_WMDE i'm more along "ewww, traits", but that's just me ;p [22:30:27] TimStarling: Yes. Basically https://gerrit.wikimedia.org/r/#/c/258151/, although that specific patch needs some cleanup. [22:30:28] MaxSem: I'd much rather see ContextSource die [22:30:34] We shouldn't need it [22:30:50] #info created https://phabricator.wikimedia.org/T124987 for mediawiki-containers migration improvements [22:31:06] DanielK_WMDE: yes and I think we wanted to reevaluate afterwards at the begining of next year, i.e. now? [22:31:09] Alphos: it encourages the wrong thing, but it has valid use cases. [22:31:24] anomie: we can just discuss it on gerrit [22:31:50] gwicke: yay [22:31:54] I can make a note on the RFC task that we're not approving the idea that traits are "verboten" [22:31:55] I vaguely remember that the PHP side of OOJSUI has bits of code that would benefit from traits. I think I remember that they did mixins with __call() magic [22:31:57] jzerebecki: well, we can evluate only after we have made some experiments... [22:32:06] jzerebecki: anomie: there's nothing stopping you from filing another RFC to say "traits on everything! long live traits!" ;-) [22:32:17] bd808: Yeah. [22:32:34] DanielK_WMDE i accept that - i've just never really met one ; usually classes separated for no good reason when the trait could have been ported in the parent ; which indicates a bad inheritance tree [22:33:03] traits make people lazy in building inheritance trees properly :/ [22:33:03] i think the tenor regarding traits was "discouraged, allow careful experiments" [22:33:08] which is basically the "tolerated" list [22:33:09] Alphos: code sharing via subclassing is even worse :D [22:33:21] geduldet? [22:33:22] ... [22:33:25] i.e. the task description should be edited so that traits are on the tolerated list [22:33:33] I'll do that [22:33:33] ori: indeed [22:33:34] right now [22:33:39] (edit the task) [22:34:25] thanks ori [22:34:25] Alphos: composition ftw! But there are legit use cases for sublcassing, too [22:34:34] probably more than for traits [22:35:28] I think it will be easier to discuss traits in specific cases on gerrit rather than in general [22:35:33] i don't really like having to search a trait to know what my class does :/ [22:36:23] as for inheritance, at least i know my dog is an {animal (eats, drinks, and poops)} ;) [22:36:45] inheritance makes sense ; composition is too abstract for my taste ;) [22:36:46] Alphos: so to search for the subclass is better how? [22:36:47] Surely we've done it in general? There's cases they can be used, but just because you can, doesn't mean they should :) [22:37:06] Alphos: yea, but something like ContextSource is bad as a trait, but worse as a base class. [22:37:09] jzerebecki because i know what the parent class does, merely by its name [22:37:11] Alphos: did you see the two patches MaxSem linked to above? I think the best way to make your case is to discuss those examples specifically. [22:37:22] Reedy: which could probably be said about most things [22:37:30] Alphos: why isn't that true for a trait? [22:37:36] ori nope, scrolling back [22:37:37] the second patch, first was an error [22:37:47] jzerebecki because traits are shared among unrelated classes [22:38:00] Alphos: because "context sources" is a purely artifical construct, not a natural concept in our domain model. [22:38:24] anyway, let's not get side tracked on discussions about coding paradigms ;) [22:38:27] #link https://gerrit.wikimedia.org/r/#/c/255484/ [22:38:28] Changing the php version in master is a one line change :) [22:38:43] Alphos: how does that ensure that the name of a trait conveys less information than that of a subclass? [22:38:46] DanielK_WMDE agreed [22:38:54] ostriches: Well, the README too. [22:39:15] so... after today, when CI will actually permit us to merge 5.5 code? :) [22:39:35] jzerebecki how many parent classes can one class have vs how many traits ;) [22:40:02] ostriches: At least 2? PHPVersionCheck and composer.json [22:40:09] Ah, silly json [22:40:37] plus INSTALL and RELEASE-NOTES :) [22:40:38] ...and the release notes [22:40:39] ostriches: I can make PHPVersionCheck read its value from composer.json if you want. ;-) [22:40:43] and the installation guide [22:40:48] and... quite a few things :) [22:40:58] ostriches: would it be fair to ask that your team take on the work of updating CI for the version requirement change (it looks like most of the work is done) and announcing the official start of the 5.5 era? [22:41:02] James_F: good idea [22:41:19] MaxSem has a point about the CI infrastructire. If it's running 5.3, we should file a task to upgrade it to 5.5. [22:41:26] * ostriches licks a cookie [22:41:28] jzerebecki: No, it's a joke. composer.json isn't shipped with the tarball. [22:41:32] but i'll point out i've never patched MW officially, all this is just a personal view ;) [22:41:35] DanielK_WMDE: legoktm did most of that work this weekend [22:41:36] there's one, I was asking when it can be done [22:41:44] Reedy: yay! [22:41:46] check experimental will do 5.5.9 [22:42:10] ostriches: is that a yes? :) [22:42:17] Just need to move zend–533 to non-voting and zend-559 to normal voting and 'done'. [22:42:19] Yes [22:42:30] ostriches: \o/ [22:42:35] \m/ [22:42:42] James_F: Can we do that on a MW version case? [22:42:58] Reedy: Yes. [22:43:14] Reedy: (So REL1_26 and before will be kept as 533-compat.) [22:43:14] #action RelEng to verify / announce readiness of CI infrastructure for min. version change [22:43:22] Yeah [22:43:28] James_F: I'd suggest to ditch 533 and add a non-voting test run for a higher version, say, 5.7 [22:43:40] you mean 7.0 [22:43:55] DanielK_WMDE: We need 533 for REL1_23 and other versions < REL1_26 [22:44:02] i mean, if we don'tsupport it, why should we run tests against it? It#S more relevant to see whether our code works with more recent versions [22:44:07] *< REL1_27 [22:44:13] it goes 5.6 -> 7.0 [22:44:25] and 7.0 is weird and different and we should support it if we can [22:44:27] Reedy: oh right... and they con only be configured per repo, not per branch? [22:44:35] DanielK_WMDE: PHP7 is a bit more work on the CI side. we don't have a system for managing multiple PHP installs in place yet [22:44:37] That's quite a few wasted cycles... [22:44:38] yea 533 should be skipped on amster and 1.27 [22:44:44] DanielK_WMDE: James_F says we can do it per branch [22:44:48] DanielK_WMDE: We mustn't break 5.3 compat. for old release branches. [22:44:54] #info and 7.0 is weird and different and we should support it if we can ; DanielK_WMDE: PHP7 is a bit more work on the CI side. we don't have a system for managing multiple PHP installs in place yet [22:45:05] thx ori [22:45:13] DanielK_WMDE: if we run 7.0, it should be voting [22:45:14] php 7 is not so different for simple stuff ; few B/C breaks, but not really much if you wrote clean interpolations [22:45:16] bd808: i'd probably go for separate vms, like travis does [22:45:30] That's what we do with 12.04/14.04 [22:45:31] DanielK_WMDE: they actually have all the PHP's in the same VM [22:45:34] DanielK_WMDE: travis uses containers [22:45:35] speaking of travis [22:45:42] using phpenv to swtich [22:45:42] i did set up travis CI for mediawiki [22:45:43] well, they want to move to it [22:45:49] and partly did already [22:45:50] jzerebecki: probably [22:46:01] i think that is still working. no reason not to rely on that for testing php 7, imo [22:46:03] hoo: or that ;) [22:46:33] ori: Other than it'd be post commit testing? [22:46:33] ori: cool! is there a way to expose this in gerrit? [22:46:36] ori: it at least gives a post merge sanity check. Not as fancy as the cross repo tests we have in Jenkins [22:46:38] looks like Jeroen already added travis support for 7.0 [22:46:38] https://gerrit.wikimedia.org/r/236596 [22:46:56] DanielK_WMDE: different vms doesn't help with different php versions as you need a package for them. if you need to build them it is easy to have multiple php versions around. that is also how travis does it. they have all php versions available in the same containter. [22:47:08] Guess we need to add 5.5.9 to travis too [22:47:20] https://gerrit.wikimedia.org/r/#/c/266931/ is a thing now [22:47:30] ori: iirc, their stuff is pretty tighly bound to github. But perhaps we can convince them to work on integrating with phabricator/differential [22:47:46] https://travis-ci.org/wikimedia/mediawiki -- builds are broken :/ [22:48:21] one test failure, LBFactoryTest::testLBFactorySimpleServers [22:48:51] which is good news, I was worried the mediawiki bootstrapping code was broken, but it looks like the test suite runs and it's just that one test failure [22:49:00] LBFactoryTest::testLBFactorySimpleServers fails [22:49:06] hrrrm. [22:49:18] oh, i was slow [22:49:26] propagating information from travis to gerrit would be useful [22:49:40] very [22:49:51] ori, as non-voting though [22:49:54] * ori nods [22:49:55] DanielK_WMDE: there are ways to integrate with Travis but they have been rejected from mainline Gerrit/Jenkins use due to the external dependencies. I can dig up really long discussions if you are truely interested. [22:49:58] ori: it would be more usefull to run those tests in our CI directly [22:50:00] i've seen "cindy the browser bot" reviewing commits, who wrote that? [22:50:04] #idea ori> propagating information from travis to gerrit would be useful [22:50:13] ori: jdrobson [22:50:35] i'll file a quick task [22:50:38] so we can link to it from the minutes [22:50:42] ori: but setting up travis to run against proposed changes is tricky, iirc. [22:50:49] is it even possible? [22:51:01] #idea jzerebecki> it would be more usefull to run those useful test that someone runs in travis directly in the WM CI [22:51:19] finding out post-merge is worse than finding out pre-merge, but better than not finding out at all [22:51:22] DanielK_WMDE: you can do it by pushing to a branch in github. cscott wrote some things that show it is possible. [22:51:31] DanielK_WMDE: it is, but I -2-ed them [22:51:42] bd808: would be nice if we could manage without github, though [22:52:01] Sure! We just need more than 1 FTE on CI infrastructure :) [22:52:06] I don't agree [22:52:30] has onyone talked to the travis guys? [22:52:44] we had them visit the office in berlin a few years back. [22:52:48] I don't see a reason not to rely on Travis for this. We'd still have our own infra for testing code changes against versions we use in production [22:52:54] i think they are oin berlin, or at least in germany. [22:53:00] and if they turn evil and we have to implement it ourselves, we're no worse off [22:53:07] * robla notes that DanielK_WMDE probably means "travis folks" :-) [22:53:28] hehe, indeed [22:53:48] replicating all of travis functionality in-house would be quite expensive, without much tangible benefit [22:53:53] dudes! [22:53:56] and dudettes! [22:53:58] bd808: only if we need our stuff to work, we probably don't, right? [22:54:18] gwicke: but we already did [22:54:26] not really [22:54:40] jzerebecki: probably don't what? Need more support for CI infrastrucutre? [22:54:57] bd808: for our code to actually work ;) [22:55:30] Travis has a much broader base image that the test from. Lots of services like Cassandra for example that they allow. [22:55:37] we have been using travis for node projects for a while now, and it has worked well [22:55:47] seems like we should probably start wrapping thigns up now, and take the travis debate to #wikimedia-tech [22:55:52] their base image is kind of huge actually [22:55:56] each commit is tested against several node versions [22:56:13] #link https://phabricator.wikimedia.org/T124999 [22:56:18] ("Propagate build status from Travis CI back to Gerrit ") [22:56:22] thanks ori ! [22:56:52] #info see related discussion at https://phabricator.wikimedia.org/T78410 [22:56:58] ori: or to phab, actually. file a ticket every time travis breaks ;) [22:57:10] or to phab, yeah [22:58:04] DanielK_WMDE: it breaks usually every day unless you pay them [22:58:09] ok [22:58:15] concluding remarks / #action / #info ? [22:58:33] eulogies for 5.3? [22:58:56] the golden days when PHP was a lot slower [22:59:09] farewell to register_globals, [22:59:36] ok [22:59:39] TimStarling: #endmeeting? [22:59:41] we'll miss you (not) [22:59:49] still a few more seconds left of the hour ;) [23:00:02] mustsaysomethingprofound [23:00:03] #endmeeting [23:00:04] Meeting ended Wed Jan 27 23:00:03 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:00:04] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-27-22.01.html [23:00:04] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-27-22.01.txt [23:00:04] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-27-22.01.wiki [23:00:04] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-01-27-22.01.log.html [23:00:15] heh [23:00:43] bye everyone [23:00:50] bye 5.3! [23:00:51] TimStarling: thanks for chairing! [23:01:50] \o/ [23:02:45] meetbot links filed at https://phabricator.wikimedia.org/E137