[12:59:36] #startmeeting Language Engineering office hour - November 2015 [12:59:36] arrbee: Error: Can't start another meeting, one is in progress. Use #endmeeting first. [12:59:52] uggh... wonder who forgot [12:59:55] #endmeeting [12:59:55] Meeting ended Wed Nov 25 12:59:55 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [12:59:55] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-24-16.03.html [12:59:55] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-24-16.03.txt [12:59:55] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-24-16.03.wiki [12:59:56] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-24-16.03.log.html [13:00:00] #startmeeting Language Engineering office hour - November 2015 [13:00:00] Meeting started Wed Nov 25 13:00:00 2015 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot. [13:00:01] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [13:00:01] The meeting name has been set to 'language_engineering_office_hour___november_2015' [13:00:56] https://plus.google.com/u/0/events/cprj7uhtiercilrilp2gfpca8dg [13:01:04] broadcasting live as a hangout on air [13:01:44] o/ Hi arrive. [13:01:53] arrbee^ [13:02:04] arrive: Can you give me the stream link? [13:02:05] Hi, all! [13:02:07] Hi Niharika [13:02:15] Hi kart_! [13:02:46] http://www.youtube.com/watch?v=eYWZ6C4N93Y does this work? [13:03:08] Yes, it does. Thanks Nikerabbit. [13:04:14] hey Niharika [13:08:33] It'd be nice if people not speaking could mute. Lots of noise. [13:11:42] Niharika: it's better now, right? [13:11:56] Much better. [13:18:26] From hangout chat: Esperanto translation competition: https://eo.wikipedia.org/wiki/Vikipedio:Konkurso/2015 [13:23:59] https://en.wikipedia.org/wiki/Special:ContentTranslationStats This is REALLY cool. It's going up all the way. [13:25:04] Is http://recommend.wmflabs.org/#Recommend maintained by the Language Engg team? If yes, can we pretty please get Hindi in there as well? [13:26:09] Niharika: no it's not maintained by us [13:26:48] Niharika: our contact is Leila [13:28:25] in research team [13:28:43] Niharika: or Ellery [13:29:48] Niharika: it should be available for Hindi too [13:29:53] *will be [13:29:55] I see. [13:29:59] http://recommend.wmflabs.org/api?s=en&t=hi&article=Hindi [13:29:59] Oh, good. [13:30:10] And where do the suggestions in https://en.wikipedia.org/wiki/Special:ContentTranslation?campaign=contributions-page come from? [13:30:26] They don't seem to be same as the ones in the Recommend tool. [13:31:00] Niharika: partially from the recommend tool and partially from other sources, depending on language pair [13:31:13] Okay. [13:33:23] Niharika: suggestion related code is currently under development, so that things will change a bit in the coming weeks as we progress [13:34:02] Nikerabbit: When I first click on "Translations" under "Contributions", I land up on the "In progress" tab with a blank "More suggestions" heading in the middle of the page, with no suggestions below it. [13:34:28] Okay. Maybe make people with no in progress translations land on the Suggestions tab instead. [13:34:57] Niharika: exactly, those things can still change, and Pau is currently giving a demo :) [13:35:40] Also, when I click on the Suggestions tab for the first time, I see only one suggestion and then I have to click the Refresh link to see more. [13:36:45] arrbee: Q: Is the "campaign" in any way related to Wikiprojects? Can they be? [13:39:02] I like the idea of having campaigns. Brilliant. [13:41:36] Niharika: yep [13:48:35] That helps, thanks arrive. [13:48:38] arrbee: ^ [13:48:42] Sorry. :/ [13:48:46] lol [13:52:58] Really bad, yep. [13:53:22] :) [13:54:47] https://ko.wikipedia.org/wiki/%EC%9C%84%ED%82%A4%EB%B0%B1%EA%B3%BC:%EB%AA%A8%EB%93%A0_%EC%96%B8%EC%96%B4%EC%9D%98_%EC%9C%84%ED%82%A4%EB%B0%B1%EA%B3%BC%EB%A7%88%EB%8B%A4_%EA%BC%AD_%EC%9E%88%EC%96%B4%EC%95%BC_%ED%95%98%EB%8A%94_%EB%AC%B8%EC%84%9C_%EB%AA%A9%EB%A1%9D/%ED%99%95%EC%9E%A5%ED%8C%90/%EB%AC%BC%EC%83%81%EA%B3%BC%ED%95%99 [13:55:08] Sorry it is Korean. I feel the list is not organized. [13:55:35] We need to organize them for the machine to read. [13:55:37] https://www.mediawiki.org/wiki/Content_translation [13:59:44] https://twitter.com/WhatToTranslate [14:01:04] #endmeeting [14:01:04] Meeting ended Wed Nov 25 14:01:04 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [14:01:04] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-25-13.00.html [14:01:04] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-25-13.00.txt [14:01:05] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-25-13.00.wiki [14:01:05] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-25-13.00.log.html [14:01:07] Thanks for organizing this, arrbee. :) Awesome work, everyone. [14:01:33] Thank you Niharika.. glad you could make it :) [16:40:09] * qchris foo [21:48:41] TimStarling: https://en.wikipedia.org/wiki/Talk:Commitment_ordering#The_Raz_infection_is_spreading is pretty amusing [21:48:50] I keep running into that stuff reading articles [22:00:14] #startmeeting RFC meeting [22:00:14] Meeting started Wed Nov 25 22:00:14 2015 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:00:14] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:00:16] The meeting name has been set to 'rfc_meeting' [22:00:22] o/ [22:00:30] \o [22:00:39] o/ [22:00:43] #topic RFC: Raise MediaWiki's PHP version requirement and update coding standards | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [22:00:52] #link https://phabricator.wikimedia.org/T118932 [22:00:54] \o/ [22:02:31] fyi, next week's meeting: https://phabricator.wikimedia.org/E93 [22:02:33] \o [22:02:52] but this week: version requirements! [22:03:28] so, what are the questions we want to answer in this meeting? [22:03:57] we could decide to port mediawiki to hack :) [22:04:00] I have some ideas: [22:04:12] * 5.4 vs 5.5 vs 5.6 [22:04:18] - do we want to raise the minimum version requirement? - if so, to what version of PHP? - what updates do we need to make to our PHP coding standards? [22:04:33] * traits [22:05:01] DanielK_WMDE: and go straigt to php 7 [22:05:09] of course [22:05:34] So, regarding the target version: I don't think it makes sense to leapfrog over 5.4, especially not after being on 5.3 for so long. [22:05:50] When is the EOL for 5.4? [22:06:11] #info public statement is https://www.mediawiki.org/wiki/Manual:Installation_requirements , also "Requirements in short" [22:06:18] It would be good to decide on a cadence for future version changes, though, and to have some means of getting feedback from third-parties on how disruptive the change to 5.4 was/is for them. [22:06:20] ori: cool that you will be personally providing security releases for php 5.4 [22:06:28] 5.4 is already EOL [22:06:30] Oh, I see. 5.4 is already EOL. [22:06:32] #link https://secure.php.net/supported-versions.php [22:06:50] 5.4 is a no go [22:06:53] So… we want to encourage people to upgrade from 5.3, but not to a supported version? [22:06:55] I may have misunderstood, but I thought PHP 5.4 is eligible for security updates by dint of being included in some LTS Linux releases [22:07:11] one intensive to migrate out of 5.3 is we still maintain a custom .deb package for it and it is already eol [22:07:13] (Also, 5.5 is only supported even for security releases for another 7 months?) [22:07:16] there is a trade-off between frequency of breakage and severity of breakage [22:07:23] also, keep in mind that we are on 5.3, so we are not losing support [22:07:24] it seems a todo for someone is to add the minimum HHVM we support, or is HHVM support unofficial? [22:07:31] yeah, the distros will attempt to backport security updates themselves [22:07:46] wheezy has PHP 5.4, but the "LTS" for that is not officially supported by debian AIUI [22:07:52] spagewmf: I think it is a TODO, yes. [22:07:53] but the statistics Nikerabbit posted are a bit scary [22:07:59] Yeah. [22:08:00] spagewmf: yes we should add that [22:08:06] https://phabricator.wikimedia.org/T118932#1813219 [22:08:12] How long did we wait to wish to upgrade from 5.3 to 5.4? Will we realistically bump from 5.4 to 5.5 in a year's time? [22:08:32] well, let's first establish consensus around raising the version requirement at all [22:08:36] Sure. [22:08:48] Also, wheezy loses security support in February 2016, which is before 1.27 comes out [22:08:50] my preference is for 5.5 [22:08:58] TimStarling: how come? [22:09:06] #info please document mediawikis hhvm version requirements [22:09:16] not disrupt users twice in a short period of time? [22:09:37] yeah, that is part of it [22:10:00] debian doesn't support 5.4 [22:10:09] there's no reason to go up by increments of 0.1, especially when the gap between updates is so long that upstream has released more than a 0.1 [22:10:27] we could always say, we're raising the min version to 5.4, but if you're going to upgrade, you may as well update to 5.5+, since we'll be switching to that soon [22:10:41] I don't think we want to end up supporting 5.4 for 3 years from now if 1.27 is LTS [22:10:49] 5.5 has useful features which I think we should take advantage of [22:11:06] generators especially [22:11:11] Wait. [22:11:16] * ori waits. [22:11:20] James_F: await? [22:11:24] I thought it was declared we would never do MediaWiki LTS ever again. [22:11:29] legoktm: good point [22:11:33] hi stuwest [22:11:47] James_F: {{cn}}? [22:11:54] legoktm: Did o.striches and g.reg-g reverse their position? [22:12:08] Settling on 5.5 seems OK to me, but it makes it even more urgent to set some restrictions on introducing new features to Core. [22:12:09] we've had this discussion about debian stable and ubuntu LTS in previous PHP version updates [22:12:17] https://www.mediawiki.org/wiki/Version_lifecycle says 1.27 is LTS [22:12:18] debian stable is 5.6.14 [22:12:24] ori: I'm pro raising requirement-- several security-impacting features have been released since 5.3.2, like the bcrypt fix, hash_equals, etc. [22:12:30] which would be an argument for going to 5.6 [22:12:42] https://packages.debian.org/jessie/php5 [22:12:49] * robla doesn't know why James_F tried to avoid pinging greg-g and ostriches [22:12:55] legoktm et al, also https://www.mediawiki.org/wiki/Category:MediaWiki_version_information_templates [22:13:00] robla: sssh! [22:13:00] legoktm: James_F: for MW future LTS no decision has been made. [22:13:16] legoktm: That claim was added last month by Kghbln - https://www.mediawiki.org/w/index.php?title=Version_lifecycle&diff=1917771&oldid=1912162 [22:13:28] I was just trying to find that :) [22:13:48] Well, we can't go past 5.5 because of Wikimedia's requirements [22:13:50] I am against adding claims about us doing 'long term support' for third parties when we don't even do short-term support. It's just a lie. [22:14:13] and it would be unfortunate if there were no ubuntu LTSs that could run MW (trusty is 5.5) [22:14:16] robla: Because Greg said he wasn't meant to be on IRC and I didn't want to lure him in. [22:14:33] * AaronSchulz leans toward 5.5 [22:14:37] OK: would the following be a fair summary of the consensus so far: * Yes, we should update the version requirement. * 5.4 is too old. [22:14:37] MW LTS has nothing to do with this discussion, does it? [22:14:52] TimStarling: Only if we're making decisions about support in MW LTS releases. [22:15:14] just to clarify: we can't got 5.6 because HHVM doesn't fully implement 5.6 features right? [22:15:21] hashar: sure it does [22:15:26] 5.6 is an option [22:15:27] HHVM doesn't fully support 5.3 features [22:15:27] Deciding to support PHP5.4 for a year (non-LTS) and 3 years are pretty different IMO [22:15:30] (interesting the php 7.0 in debian is parallel installable to 5.6) [22:15:31] TimStarling: ha ha [22:15:58] hashar: well, Wikimedia has silver, which is running php5.5, not hhvm https://phabricator.wikimedia.org/T98813 [22:16:23] #info There is consensus for raising the version requirement, and that we should raise it to something newer than 5.4. [22:16:24] I am trying to dismiss legoktm claims that "we can't go past 5.5 because of Wikimedia's requirements" [22:16:34] hashar: legoktm is right, though [22:16:39] the snapshot hosts are on 5.5, too. [22:16:41] the policy should be that our minimum is either 5.5 or some version of HHVM, maybe 3.1 [22:16:53] which means that our unit tests should be run against both [22:16:53] which should be because of us still having Trusty. But AFAIK WMF ops are working toward migrating to Jessie [22:17:10] yeah, everything new is jessie [22:17:12] and if snapshot hosts are the last Trusty box using MW, we would want to prioritize their migration to Jessie [22:17:24] and so effectively, our minimum version will be the common subset of features supported by PHP 5.5 and HHVM 3.1 [22:17:36] then wikimedia can be cleared for 5.6 (and whatever hhvm match it) [22:18:00] WMF's requirements shouldn't be the reason we decide for third parties, they should just delay such a change, though? [22:18:01] anyone want to OPPOSE tim's proposal, before we add it as #info and declare it settled? [22:18:20] Not I. [22:18:30] robla told me to +1 so +1 [22:18:45] * ostriches is clearly a meatpuppet here [22:18:48] what is the proposal again ? [22:18:55] "our minimum version will be the common subset of features supported by PHP 5.5 and HHVM 3.1" [22:19:02] +1 [22:19:04] " and so effectively, our minimum version will be the common subset of features supported by PHP 5.5 and HHVM 3.1” [22:19:10] isn't that 5.3? [22:19:14] +1 [22:19:20] +1 [22:19:20] +1 [22:19:25] what's the delta between HHVM 3.1 and 5.5? [22:19:26] #info TimStarling: our minimum version will be the common subset of features supported by PHP 5.5 and HHVM 3.1. (No objections.) [22:19:37] SMalyshev: HHVM targets compatibility with 5.6 [22:19:56] oppose: It's a little hard to put that (usefully) on the download page and expect admins to figure out what php version they need to run to run mediawiki [22:20:01] " HHVM doesn't fully support 5.3 features" was a joke, we had some bad experiences with the compatibility [22:20:06] SMalyshev: you know that they completely rewrote the runtime, often without even reading the manual properly, let alone the PHP source [22:20:21] hhvm is AFAIK already targeting some php 7 features [22:20:21] SMalyshev: stuff like this i guess: https://github.com/facebook/hhvm/issues/3193 [22:20:30] though in that case, hhvm is just failing to fail... [22:20:34] csteipp: we just put 5.5 on the download page [22:20:35] csteipp: Won't the requirement be for developers, not sysadmins? [22:20:38] I agree with csteipp that the statement should be more explicit [22:20:42] (What ori said.) [22:20:47] DanielK_WMDE: ah, that's small time problems [22:20:48] so there are some missing details, but officially they track some fairly recent PHP version [22:21:14] delta between 5.5 and 5.6 is not large, so sounds good [22:21:17] SMalyshev: until it bites you in the ass ;) [22:21:39] Admins only need to know 5.5+; developers should know to avoid features that suffer from compat issues on HHVM, but the unit tests should point those out anyway. [22:21:46] I think where the HHVM vs PHP delta comes into play is if/when a developer tries to submit something for code review that doesn't work in one or the other [22:22:01] But that's why we have the -hhvm and -zend CI pipelines. [22:22:05] Requirements will say "our minimum version is PHP 5.5 and HHVM 3.1", and Coding conventions/PHP and Developer guidelines will say "You must code to the common subset of features supported by PHP 5.5 and HHVM 3.1" [22:22:06] csteipp: for sysadmins, I would instruct to get Zend 5.5 at least. Potentially add reserve note regarding Zend 7 and an hint about HHVM 3.1 [22:22:17] HHVM compatibility is really pretty good these days [22:22:18] So hopefully we spot them before merge. [22:22:33] DanielK_WMDE: https://github.com/facebook/hhvm/issues/1027 ;) [22:22:44] James_F: if folks write tests covering the code paths yes :-} [22:23:26] ori: I'm fine with that. Just concerned something will be fixed in a minor 5.5 version (like bcrypt being fixed in 5.3.7), and then we're stuck having to support both in our code. I'd rather be explicit. [22:23:29] AaronSchulz: PHP 7 would do the same AFAIR [22:23:34] #info Requirement statement for users: PHP 5.5+ or HHVM 3.x+ ; requirement statement for developers: the subset of features that behave consistently on both platforms. [22:23:58] the reason I say 3.1 is because IIRC that was the git master release when I was adding features needed by MW, during our migration to HHVM [22:24:02] SMalyshev: I still never audited all our callers...could be some bugs out there in MW [22:24:11] I vote that only master of MW / hhvm / zend are supported. If you're not on master then toooooooo badddddddd :) [22:24:17] (other than the one I ran into) [22:24:20] so 3.1 was effectively the first version we used on the cluster [22:24:44] note that CI currently runs tests against Zend 5.3 and HHVM 3.6.5. [22:24:55] anyone using HHVM right now is comfortable running / building beta-quality software [22:25:02] so the HHVM minimum version requirement can be much more aggressive [22:25:09] +1 to ori [22:25:21] I'd also go higher than 3.1, tbh [22:25:29] gwicke: me too, but [22:25:29] ostriches: i'd agree if you keep gerrit upgraded to master [22:25:36] this seems to me less important to nail down than revised coding standards [22:25:42] Is there a standard HHVM package level in distros? [22:25:48] James_F: no [22:25:49] ok, we can say 3.6 for MW git master [22:25:56] OK then. [22:25:56] jzerebecki: touché [22:26:05] #info HHVM min version: 3.6 for MW git master [22:26:21] more honest since that's what's being tested [22:26:22] #info We're not picking 5.6 because Ubuntu LTS (14.04) packages 5.5 [22:26:32] ^ hope that's right [22:26:42] but maybe good to make the installer not fail if it sees HHVM 3.5 or something? [22:26:52] #info and because wmf cluster still has some machines on 5.5 / trusty [22:26:54] HHVM 3.6 is a soft requirement, for the download page [22:26:58] * James_F nods. [22:27:00] not a hard requirement [22:27:07] TimStarling: We could make the installer version checks more fluid. [22:27:16] #info HHVM 3.6 is soft requirement for the download page, not hard requirement [22:27:16] Instead of if < N die [22:27:19] Can we retain the installer at 5.3? 5.4? [22:27:23] * James_F just asks. [22:27:28] can we move on to policy on language features? [22:27:49] James_F: "Yes" until something you use in the installer bumps to beyond 5.3/5.4 [22:27:49] yea. no traits please. [22:27:56] if we allow generators (and I think we should) then 5.5 will be a hard requirement [22:28:04] So to recap, PHP 5.5 / HHVM 3.6? [22:28:15] legoktm: yes [22:28:25] my position was expressed most eloquently by HappyDog on phab: "There are a number of situations for which traits are the best solution, but on a large open-source project that attracts a lot of relatively inexperienced new contributors, I would say it would save a lot of time simply to disallow their use than to continually be rejecting commits and having to explain why traits are the wrong solution over and over again." [22:28:26] whoa? I personally like traits as long as you don't use them to implement multiple inheritance a-la C++ [22:28:51] yeah, I would like to have trait-hate explained to me please [22:29:00] i'd like traits please [22:29:05] ori: +1 [22:29:18] oh, generators would be nice indeed. [22:29:27] and non-sucky closures. [22:29:35] #agreed bump requirement to PHP 5.5 / HHVM 3.6 matching Zend version on Ubuntu Trusty and HHVM version on WMF cluster. [22:29:54] DanielK_WMDE: If I got one thing, and one thing only of upgrading, it'd be to stop using $that = $this; use $that in closures :p [22:29:57] yes, obviously we can approve use of $this in closures, and even bulk migration [22:30:12] * AaronSchulz mourns $that [22:30:14] ostriches: word! [22:30:24] Ok, take namespaces -- namespaces are presumably even less controversial (and more obviously useful) than traits. They introduction to the code base may have been unavoidable, but it has been a mess [22:30:46] the \MediaWiki namespace is used by the at-ease extension [22:30:59] ostriches: i think i need that on a t-shirt: $self = $this; or self = this, for the JS types. [22:31:02] and we have things like \MWTimestamp [22:31:20] ori: Namespaces are a pain in the rear to introduce to existing codebases in a way that preserves back-compat. [22:31:33] ostriches: right, and I would argue that this applies to other language features. [22:31:38] regarding traits, consider ContextSource [22:31:53] DanielK_WMDE: timely in both languages, now that arrow functions are becoming available in JS [22:31:57] +1000000 [22:32:10] I didn't like ContextSource from the outset, unfortunately I was too late to block it pre-merge, but I did have a bit of a whinge afterwards ;) [22:32:13] TimStarling: yeah, maybe some monolog interface boilerplate too [22:32:23] but we now have a lot of classes that extend ContextSource [22:32:25] * AaronSchulz is pro-trait [22:32:27] namespaces affect how the class is used by other code, traits don't [22:32:29] the problem is that you can't (imo) effectively restrict it to that [22:32:31] I would not veto Traits on principle [22:32:37] it's an implementation detail [22:32:52] it has a lot of useful case, but maybe introduction of a new trait should be subject to prior discussion [22:32:54] we're going to end up with some awful things in core [22:32:59] extension should be for implementing abstract stuff, not just random code reuse [22:33:15] hashar: I'd be OK with that as a compromise [22:33:23] ori, that sounds very defensive [22:33:23] AaronSchulz: +1 [22:33:25] what ori seems to be arguing for (and I agree) is to start off conservative with language features that are newly available to our codebase [22:33:29] yeah, of course you can use traits in a stupid way, you can use inheritance in a stupid way [22:33:32] and we have done [22:33:41] it's not like 5.3 doesn't give you plenty oppurtunity to do awful things [22:33:51] as an example, https://github.com/php-fig/log/blob/master/Psr/Log/LoggerAwareTrait.php is a trait I'd like pretty much everywhere we have something implementing Psr\Logger\LoggerAwareInterface [22:33:52] *cough* LSB *cough* [22:33:53] so by default we would reject Trait and if someone comes up with a strong use case (maybe via an RFC) we would accept use of Trait as an exception [22:33:55] tgr ^ [22:33:59] we're not considering the use of traits for a new, as-yet-unwritten project [22:34:03] ostriches, stabstabstab [22:34:05] because sometime, Trait just make sense. [22:34:17] TimStarling: is it harder to abuse inheritance than trains? [22:34:18] tgr: perl also gives you the ability to do awful things. perl + coding standards is *almost* tolerable [22:34:20] we're considering introducing them to a massive codebase that was written without traits [22:34:43] yeah, I don't really buy it [22:34:44] what worry me is that people start introducing a bunch of traits everywhere without any clue about the long term impact to our codebase [22:34:52] if forbidding language features is the only mechanism we have to prevent awfulness in core, then we have a problem, and that problem is not traits [22:34:59] hashar: people already do that with inheritence [22:35:06] +1 tgr [22:35:18] probably what jzerebecki was getting at [22:36:40] * gwicke is more worried about lack of tests than traits [22:36:50] tgr: yes, we have a problem [22:36:55] is it practical to monitor usage of traits? can e.g. the gerrit reviewer bot add reviewers on patches with traits? [22:37:00] if someone is badly using traits they'd probably just badly use inheritance anyway (where composition or something would be better) [22:37:00] AaronSchulz: let not add more cruft by doing it as well with traits ? [22:37:25] also, making a rule also prevents use of traits when it *would* be better [22:37:42] gwicke: heh [22:38:30] hashar: why does it matter whether the mess is a inheritance or a trait? A mess is a mess :) [22:38:30] we have PHP CodeSniffer running at least on core [22:38:47] can we come up with coding standards on how to do traits right, or is it an "I know it when I see it" litmus we want to apply? [22:38:52] " If a trait defines a property then a class can not define a property with the same name, otherwise an error is issued. It is an E_STRICT if the class definition is compatible (same visibility and initial value) or fatal error otherwise. " [22:39:00] so potentially we could make it fail when a Trait is introduced. But for extensions CodeSniffer is far from being installed everwyereh [22:39:15] I don't like the idea of accidentally conflicting property names [22:39:19] AaronSchulz: what I meant is having to deal with trait mess in addition to class mess. Double mess! [22:39:19] I'd second what tgr said, we are screwed already if such rules are the only way to try to avoid messes (and I'm not sure the rule would help messes either) [22:39:29] will an E_STRICT error cause unit tests to fail? [22:39:35] OK, I'm trying to be realistic here. It doesn't look like forbidden traits outright has a snowball's chance, at this point, so what I would like to ask is that the min version announcement be accompanied by an acknowledgement that the change brings with it a host of language features that have no precedent in the codebase, and that developers should be act with maximal restraint and allow usage to be introduced gradually and [22:39:36] conservatively. [22:39:55] maybe we can detect such conflicts by static analysis [22:40:14] add a CI check that any use of traits must have a cryptographically secure // Signed-off-by: tstarling ElF2BYRywNt [22:40:15] would be nice, same with non-private methods and inheritence [22:40:36] +1 to any static analysis [22:40:49] looks like https://www.mediawiki.org/wiki/Git/Reviewers only handles filename regexps now, how about adding git pickaxe style rules and then people can subscribe on patches adding a new trait and -2 to their hearts' content? [22:41:16] hah, tools I've looked at can't follow closures right. No chance they're going to trace flow through traits. [22:41:24] tgr: because the idea is not to frustrate / block, but reach an agreement [22:41:27] TimStarling: sure it will fail a unit test if the class is loaded in a test run, unless php is configured to ignore it or/and phpunit is told to ignore it [22:42:01] "+1 to any static analysis" is about as meaningful as "+1 to more unit tests" -- no one would object, but no one is volunteering either. [22:42:21] ori: I just meant that maybe having an easy way to review such changes would alleviate concerns of bad usage of traits slipping in without anyone noticing [22:42:29] ori: do you think it's likely enough that people would abuse new features more than old ones to warrant a warning that specifically focuses on them? [22:42:36] I don't think an SA tool should be a blocker [22:42:37] gwicke: yes. [22:42:47] gwicke: I have certain people in mind, too :X [22:43:10] okay ;) [22:43:11] tgr: we *could* conceivably fast track an RFC that defines proper use of traits, and block usage of traits until such an RFC exists [22:43:12] but if someone wants to do, the more the merrier. Just saying inheritance has collision problems too. [22:43:20] inheritance is here to stay [22:43:27] traits we can still opt out of [22:43:28] I see at lot of singling out of traits just because they are new [22:43:32] just checked, if you have conflicting properties, E_STRICT is raised when the class is defined, it doesn't wait until instantiation [22:43:36] TimStarling: PHPUnit has a custom error handler, it should be able to turn E_STRICT to exception and thus fail the test. [22:43:57] since we have less experience with the new features, we will have to learn to spot abuse. we just don't have any experience with traits. the change how dependencies work. we should take our time experimenting with that. [22:44:07] DanielK_WMDE++ [22:44:09] TimStarling: i don't know for sure, but i think phpunit must just be told to include that class in its coverage whitelist (possibly also enable coverage) then it will without any test ever loading that class [22:44:13] not based on any material problem being worse than existing ones (just different manifestations to me with non-meaningful distinctions) [22:44:34] #info since we have less experience with the new features, we will have to learn to spot abuse. we just don't have any experience with traits. the change how dependencies work. we should take our time experimenting with that. [22:44:52] robla: sure, if we feel like we can easily foresee all good usage patterns [22:44:58] I'm not sure about that [22:45:38] ok, did we have any other new features to discuss? [22:45:40] OK, so people have brought up Monolog, RequestContext [22:45:43] short array syntax? [22:45:51] maybe we would more discussion about trait [22:46:07] ApiMessage has api/ApiMessage.php:70: * @todo: Would be nice to use a Trait here to avoid code duplication [22:46:27] could we only allow traits there and agree to re-visit this in a couple of months? [22:46:30] TimStarling: i don't see a problem with that [22:46:35] we've waited this long, right? [22:46:41] TimStarling: +1 to [] [22:46:53] I think that is a reasonable compromise [22:47:02] I think the resolution for traits is to start writing the coding conventions document [22:47:13] ori said "but please let's not destroy our git history with changes that do nothing but update the syntax." on the RfC and I agree with that (re: short array syntax) [22:47:15] to work out what is OK and what is not [22:47:33] TimStarling: I don't agree; we'll have to do some learning by experience. [22:47:38] ori: why rush it? I would prefer a discussion to happen about ApiMessage so we can have the time to pound the pro/con of it. Risk is introducing a bad pattern that we will have to repay :-/ [22:47:55] ori: I mean at the same time as learning by experience [22:48:10] I mean that experience should translate into documentation fairly rapidly [22:48:51] without mass migration, it won't be long before the inconsistency starts getting on people's nerves [22:48:58] re short array [22:49:03] is there anyone who objects to a three-month moratorium on traits *except* for LoggerAware and RequestContext [22:49:03] oojs-ui ButtonInputWidget.php has setLabel() comment: HACK... Switching to traits will fix that. [22:49:14] with a scheduled follow-up rfc meeting [22:49:19] TimStarling: Could do one of the "either is fine, but be consistent within a file" [22:49:38] TimStarling: re: new features, there is unconstrained empty(), we should probably ban that [22:50:06] TimStarling: the other possibility is to programmatically transform the entire codebase in one go [22:50:10] if people are going to mass-migrate files, I'd rather we just do one giant commit and be over with it (breaks git blame less) [22:50:18] tgr: empty() is often misused and should be suspect anyway :) [22:50:33] I could try committing an experimental commit adding traits to ContextSource so we could see if we like it [22:50:42] perhaps someone could start the "How to use traits in MediaWiki" RFC, with the initial version being "everywhere, with abandon. rules are for losers!" [22:50:43] non-scalar keys in foreach, also seems more bad than good [22:50:45] don't like, abandon [22:50:52] yeah, personally, I would approve such a mass migration commit [22:50:55] like it, make it mergeable and merge [22:51:01] #action MaxSem to make experimental commit adding traits to ContextSource so we could see if we like it [22:51:28] why do we have to implement first [22:51:33] can't we spec it ? [22:51:42] hashar: UML diagrams? [22:51:46] the point of the RFC I'm proposing would be where we could start to document the bad ways of using traits [22:51:51] I'll declare the moratorium in an #info unless someone says they disagree [22:52:00] cause having to discuss software change on Gerrit review system is far from ideal [22:52:01] and no not UML [22:52:09] three-months, with exceptions for LoggerAware and RequestContext [22:52:30] but a simple RFC proposal would be easier to talk about than a change in Gerrit imho [22:52:42] the actual code is just a detail [22:52:44] I don't care for a temp ban, but I wouldn't "veto" it either [22:52:51]