14:00:02 #startmeeting javascript 14:00:08 Meeting started Wed Jun 29 14:00:02 2016 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:12 The meeting name has been set to 'javascript' 14:00:18 Roll call, who's around? 14:00:26 I know that vkramskikh is on vacation 14:00:27 Hello ! 14:00:33 howdy all 14:00:40 Woo, people! 14:00:42 hi! 14:00:43 o/ 14:00:47 #topic rollcall 14:00:50 #info yujunz 14:01:08 seems not chaired... 14:01:17 Sec. 14:01:26 Agenda: 14:01:28 #link https://etherpad.openstack.org/p/javascript-meeting-2016-06-29 14:01:35 * SotK watches 14:02:03 Chairs are myself and vkramsick at the moment. 14:02:19 Also, eavesdrop will list you as an attendee automatically 14:02:21 Last week in Berlin. Sorry to missed the meeting. 14:02:28 Berlin is neat :) 14:02:42 #topic js-openstacklib design: ES5 or ES6 14:03:16 vkramskikh was supposed to report back on researching the differences and nuances that come with writing in ES6 and transpiling to node/browser/es5 14:03:23 o/ sorry im late 14:03:44 I've done a bit of that myself. Best I can figure is that node4 doesn't really support es6, which is what we're currently testing on. 14:03:59 On my side I said last week that using es6 with babel was taking something like 300MB 14:04:07 but with npm3 it's not true anymore 14:04:14 It's like 50MB 14:04:26 cardeois: NPM3's not packaged with node4,. correct? 14:04:48 possible but you could in an alternative install `npm3` package 14:05:04 then `npm3 install` ... it's not perfect but if size is a matter we could use that 14:05:13 I'm afraid we can't. The constraints set on us by infra are "use a node LTS release". 14:05:50 point releases tend to be a bit too volatile. 14:05:59 ok 14:06:15 so maybe vkramskikh know more about it and we could ask him next week 14:06:20 Yep. 14:06:29 Having said that though, I was able to successfully transpile, test, and run coverage on an ES6 module. 14:06:47 awesome ! 14:06:52 It's jasmine based, so that's as yet undecided, but the review is here: https://review.openstack.org/#/c/334268/ 14:07:33 I'll have a look at them later 14:07:56 Note that this review only does testing. It basically transpiles the source during require() before feeding it to the browser/test engine. 14:08:18 me too, but is there any reason to have chose jasmine over mocha? Not sure here, but I think mocha could be run in command line with no browser (for the server side) so that could be nice 14:08:19 But it also successfully generates a coverage report for the original ES6 code, which is something I was worried about. 14:08:41 cardeois: That's a different agenda item :D 14:08:47 alright 14:09:04 I just used jasmine because it's what I was familiar with. the choice of jasmine vs. mocha is a separate discussion. 14:09:26 Alright, we still need vkramskikh to come back with his research on the topic. 14:09:32 But so far everything looks good. 14:09:34 Moving on. 14:09:52 #topic js-openstacklib design: What is server interaction approach 14:10:01 #link https://review.openstack.org/#/c/333901/ 14:10:27 There are no reviews on that spec, can I get commitments to review and comment on that spec by next week? 14:10:34 * krotscheck would like to get to a place where we can write code. 14:10:39 ++ 14:10:44 I can try yes 14:10:48 +1 14:10:53 i can 14:10:55 Thank you everyone :) 14:10:59 I will as well 14:10:59 i'm going to participate in the review too 14:11:05 Please do. 14:11:16 me too 14:11:21 The faster we get these reviewed, the faster we can write code, the faster we can ship :D 14:11:32 woot 14:11:49 (the faster we can put this into js-generator-openstack and autodetect your cloud during the bootstrapping process) 14:11:51 Next! 14:12:07 #topick js-openstacklib design: Configuring the library. 14:12:09 #link https://review.openstack.org/#/c/331801/ 14:12:50 I just severely reduced the scope of that spec. Basically it now says: "clouds.yaml permits configuring multiple clouds, but since we can't predict whether that's somethign that's required, we'll leave the reading and selection of the cloud to the user" 14:13:07 I'm envisioning something like var api = new OpenStack(config); 14:13:32 What do you mean reading? The parsing of the file? 14:13:37 Yes. 14:13:42 And autodiscovery. 14:14:22 cardeois: If you do a diff on the spec's revisions, you can see what I ripped out. That'll explain it better. 14:14:30 Ok make sense, I guess if at the end it's a dictionnary that's very similar to clouds.yaml, there should be no problem with that. The user just requires a yaml lib for javascript and he's done. 14:14:32 Ok will do 14:14:57 cardeois: Right, or a json file that looks suspiciously like a yaml file, so you don't have to pull in 100KB of yaml parser 14:15:11 More reviews requested on that one. 14:15:23 Any questions on that one? 14:15:39 ill comment if i have any later. for now no :) 14:15:48 #topic js-openstacklib design: Devstack testing 14:15:55 #link https://review.openstack.org/#/c/331359/ 14:16:01 Summary: Hey, we should gate against devstack 14:16:13 good luck with that ;) 14:16:37 tsufiev: We'd love the help of an experienced horizon dev on how to set that up properly :D 14:17:09 my jokingly tone was more related to devstack being not very stable sometimes 14:17:16 but of course, I'm exaggerating here 14:17:25 tsufiev: We'd love the help of an experienced dev to help make devstack stable :D :D 14:17:33 Does everyone agree that this is a good thing? 14:17:34 horizon integration tests recently have been runnign pretty well over devstack 14:17:42 Yes 14:18:17 oookay. Well, we'll land that as soon as we get two cores to agree. Does anyone want to take on that work? 14:19:01 I have no idea how to do that, but I can help, or get some help 14:19:30 if cardeois is in, I can be his second. As we are seated one next another, it's going to pair more easily 14:19:56 cardeois: It will likely involve a patch to openstack-infra/project-config; the openstack-infra channel's a great place to ask for help. That project's also got plenty of copy/paste examples :) 14:20:10 jprivard: Awesome, thanks 14:20:22 alright 14:20:37 #action cardeois and jprivard to work on creating a dsvm job for js-openstack-lib once the spec is approved. 14:21:08 cardeois, jprivard: I'll be on vacation starting tomorrow, so asking questions will be easier via email. I'll do my best to respond quickly: krotscheck@gmail.com 14:21:18 noted! 14:21:22 Moving on 14:21:30 #topic js-openstacklib design: Node6LTS 14:21:41 Node 6 has been out since the summit, maybe we should start using it? 14:21:51 There's come concerns. 14:21:56 Not everyone uses node6 yet. 14:22:30 larainema was going to look at updating the npm-install macro in infra to permit us to select a different version of node. 14:22:39 larainema Any progress on that? 14:23:03 yes, I can install node6 on xenial 14:23:17 larainema WOO! 14:23:23 node6 will be the current LTS starting in October. that's only a few short months away 14:23:24 but I have no idea how to leveage the old version 14:23:38 msmol: True, however node4 will continue to live on as long as xenial is the LTS 14:23:47 would installing node6 break existing npm-based jobs, krotscheck? 14:24:02 tsufiev: The hope is that the macro will be parameterized with a default of 4 14:24:15 good to know :) 14:25:06 larainema: There's a way to make a macro take a parameter. I think you can search for it in macros.yaml and look for a name: something-{variablename} 14:25:22 So if I understand properly, we want to use node6 but also be compatible with node4 right? So tests are run on both versions? 14:25:43 larainema: If you create a patch that just installs node6 instead of 4, we can investigate it together on gerrit. 14:26:03 cardeois: Well, that's part of the discussion 14:26:36 krotscheck, OK, I will do it first 14:26:37 So the first question is: Should we support node6? 14:26:52 I'm sure we'd all love to use all the awesome new features. 14:27:10 But, if our support target is node4, then we still have to transpile, so it might not be worth the effort. 14:27:40 Personally, shaking things up in Newton may not be a good idea. 14:27:55 But then we're a new project, so it matters less. 14:28:03 (It doesn't really matter at all as long as we don't break horizon) 14:28:13 Thoughts? 14:28:53 True but if we use ES6 anyway is that a problem to transpile? 14:30:03 Is that to be answered in the first topic? 14:30:18 I think so. We've figured out transpiling. 14:30:31 Or, well, I've got a draft of it anyway 14:30:50 Even there is no problem, I think it will require some extra effort. 14:30:55 Since we've decided to be isomorphic, we're deploying to browsers anyway. That means ES5 14:32:04 Ok, seems like we're not reaching a decision on this one, and few people are engaged in the discussion. 14:32:05 Yes so that means it would just be a babel configuration to add the node6 preset. If user are using old node he could use the es5 transpiled version for compatibility 14:32:25 * krotscheck stands corrected. 14:32:49 We could report the subject for next week, I'm fine with that 14:33:05 cardeois: Is there a way to make that automagic? I don't want to ask someone to `npm install` a thing and then have to do additional configuraiton if they're running on node4 14:33:48 Ok, does anyone disagree with sending this project to next week? larainema can still do his work, as it'll be necessary. 14:34:13 Agree to send it to next week 14:34:18 ++ 14:35:07 Okies, next 14:35:13 krotscheck to answer your question, I don't know... 14:35:36 #topic js-openstacklib design: Test Framework! 14:36:00 Before we argue jasmine vs. mocha, does anyone have a problem with istanbul? 14:36:08 (Code coverage. 14:36:09 No 14:36:33 reports look like this: http://logs.openstack.org/68/334268/1/check/gate-js-openstack-lib-npm-run-test/6c7e20f/cover/node/ 14:36:34 Nope good to me if it works well with es6 14:36:48 I'm fine with istanbul 14:36:55 Excellent. 14:36:57 yep looks good 14:37:06 #agreed istanbul will be used for code coverage. 14:37:26 So: jasmine vs moca. 14:37:27 *mocha 14:37:48 I'm more familiar with mocha, but ok with jasmine. 14:37:54 as for jasmine vs. mocha, it's really jasmine vs. mocha + all the other stuff jasmine provides that mocha doesn't (not necessarily a bad thing) 14:37:56 As for jasmine vs mocha, for start we need to run tests for browsers AND node directly 14:38:05 e.g. sinon 14:38:32 So are both framework able to do that? Like browsers could be handle by karma, and server would be a jasmine/mocha cli 14:39:02 I'm going to paste something I got in email from notmars 14:39:04 "Jasmine is more monolithic/tight up, Mocha gives you all the flexibility you may want (assert style, async testing, mocking…). If we were a team immature new to Javascript, I would say Jasmine to avoid the quirks of adding dependencies and managing them. But as that is not the case, I have a slight preference for Mocha, even though we need to setup it right, first." 14:39:31 This patch runs both browser and node tests: https://review.openstack.org/#/c/334268/ 14:39:39 (using jasmine and karma-jasmine) 14:40:00 (evidence: http://logs.openstack.org/68/334268/1/check/gate-js-openstack-lib-npm-run-test/6c7e20f/cover/) 14:40:08 I agree with that, I prefer mocha because we can choose what we want and how we want to test. Anyway mocha is the same syntax as jasmine 14:40:28 I expect that mocha will basically be the same. 14:40:50 I disagree that mocha syntax is the same as jasmine though. 14:41:16 Oh wait, wrong version. 14:41:21 You're right, syntax is basically identical 14:41:44 Does anyone know what fuel uses? 14:42:05 I know that all the other js projects out there (horizon, storyboard, openstack-health) use jasmine. 14:42:19 my problem with jasmine is essentially the same as what Bruno (notmars) said. it's monolithic/batteries included, whereas mocha we have the option to pick and choose the best tools 14:43:02 See, that's why I don't like mocha. Because we have to discuss and argue on what the "best" tools are. 14:43:11 And, quite frankly, bikeshedding is the death of open source. 14:43:12 Yes, but to play devil's advocate, we have to choose, so it could end up with non ending debates or bad choices. We just have to be experienced enough 14:43:25 I'd rather have a monolithic, single dependnecy, and skip all those future arguments altogether. 14:44:21 Fewer dependencies = fewer moving parts = fewer potential failures. 14:44:31 +1 I actually changed my mind, jasmine is better for an opensource project. Mocha is fine for a little team that can decide fast, but for big team with new people coming every day, we might have to justify ourselve everytime somebody challenges the choices 14:44:39 no jasmine in fuel dev dependencies 14:44:47 but mocha is used 14:44:51 jaranovich: Gotcha. 14:45:02 krotscheck: very good point 14:45:02 jaranovich: Thanks for looking that up. 14:45:28 One question: Has anyone here ever moved a project from jasmine to mocha, or back? 14:45:41 Never... 14:45:42 I'd like to get a sense of how difficult the switch would be if we decide to go the other direction. 14:46:05 i.e. cost to change our mind :) 14:46:42 Didn't do it, but if there's external libraries to support jasmine asserts/mocks/etc that might not be hard 14:47:16 But code could be messed up with old/new way to do asserts, which is bad 14:47:26 timothyb89 might have an opinion, he just wrote karma-subunit-reporter. 14:47:48 I haven't used mocha, but it does look very similar 14:47:55 never actually done it but I don't think it would be much of a pain to go from mocha -> jasmine. you can still use things like sinon/chai with jasmine, and slowly transition your tests to jasmine, whereas the other way around I feel it would have to do it all at once 14:48:08 I could try rewriting stackviz's tests to try it out :) 14:48:43 timothyb89: Naah, just trying to get as many people to pay attention to this discussion before I call a vote. 14:48:45 That's actually a good point msmol, you can run mocha tests in jasmine, so transition could be progressive 14:48:58 :D 14:49:03 +1 for jasmine if my opinion here matters, since it would ease the transition of horizon devs to js-openstack-lib, if that happens 14:49:26 Ok, talk amongst yourselves, I'm going to go figure out the voting syntax.... 14:50:09 talk? Huh, so bothersome 14:50:12 #startvote Which testing framework should we use? Jasmine, Mocha, Abstain 14:50:12 Begin voting on: Which testing framework should we use? Valid vote options are Jasmine, Mocha, Abstain. 14:50:13 Vote using '#vote OPTION'. Only your last vote counts. 14:50:36 #vote Jasmine 14:50:38 #vote Jasmine 14:50:55 #vote Jasmine 14:51:00 #vote Jasmine 14:51:01 #vote Jasmine 14:51:30 #vote Abstain 14:51:39 #vote Jasmine 14:51:49 timothyb89, betherly, yujunz, tsufiev: Opinions? Disagreeing is not looked upon negatively :) 14:51:55 Oops, nevermind 14:51:58 need to type faster. 14:52:08 #vote Jasmine 14:52:21 #vote Jasmine 14:52:30 That's definitely a quorum. 14:52:37 #endvote 14:52:38 Voted on "Which testing framework should we use?" Results are 14:52:39 Abstain (1): yujunz 14:52:40 Jasmine (8): betherly, timothyb89, krotscheck, cardeois, jprivard, tsufiev, larainema, msmol 14:52:47 Alright, jasmine it is! 14:52:49 Moving on. 14:53:11 #topic Add permanent agenda link to eavesdrop.openstack.org 14:53:23 I proposed it, so I will do it 14:53:29 Excellent, thanks! 14:53:40 I just forgot the link today and think it would be necessary 14:53:47 #action yujunz Add permanent agenda link to javascript meeting in openstack-meeting repo. 14:54:01 #topic Project Dashboard for work tracking. 14:54:07 How do we want to track work? 14:54:12 (5 minute warning) 14:54:23 Linked to the agenda issue. 14:54:34 I just can not find a start page for this group 14:54:56 * krotscheck said he'd set up a wiki a while ago, and never got around to it. 14:55:09 #action krotscheck Set up a javascript wiki 14:55:14 From there we can link to StoryBoard, etc. 14:55:22 #topic Open Discussion 14:55:45 * krotscheck is on vacation starting tomorrow, so will have limited access. 14:56:01 Comments required on IIFE removal 14:56:01 * betherly will be off monday and tuesday to deal with my house move 14:56:05 #link https://review.openstack.org/#/c/335318/ 14:57:20 yujunz: I'm in favor. 14:57:43 Actually, that begs the question about eslint rules. 14:57:59 Anyone want to start digging into those and see if we can separate those rules into "node" and "browser"? 14:58:25 I can do it. 14:58:44 I've also encounter issues on eslint version. 14:58:53 2.4.0 in eslint-config-openstack vs 1.10.3 in js-generator-openstack 14:58:56 yujunz: Yeah, you can update that whenever you want. 14:59:11 We don't have automatic dependency synchronization yet. 14:59:30 I would prefer move to 2.x 14:59:37 since this is the default stable version 14:59:59 yujunz: Go ahead :) 15:00:03 And we're done! 15:00:06 Thankss everyone! 15:00:08 #endmeeting