14:00:02 <krotscheck> #startmeeting javascript
14:00:08 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:12 <openstack> The meeting name has been set to 'javascript'
14:00:18 <krotscheck> Roll call, who's around?
14:00:26 <krotscheck> I know that vkramskikh is on vacation
14:00:27 <cardeois__> Hello !
14:00:33 <msmol> howdy all
14:00:40 <krotscheck> Woo, people!
14:00:42 <jaranovich> hi!
14:00:43 <larainema> o/
14:00:47 <yujunz> #topic rollcall
14:00:50 <yujunz> #info yujunz
14:01:08 <yujunz> seems not chaired...
14:01:17 <krotscheck> Sec.
14:01:26 <krotscheck> Agenda:
14:01:28 <krotscheck> #link https://etherpad.openstack.org/p/javascript-meeting-2016-06-29
14:01:35 * SotK watches
14:02:03 <krotscheck> Chairs are myself and vkramsick at the moment.
14:02:19 <krotscheck> Also, eavesdrop will list you as an attendee automatically
14:02:21 <yujunz> Last week in Berlin. Sorry to missed the meeting.
14:02:28 <krotscheck> Berlin is neat :)
14:02:42 <krotscheck> #topic js-openstacklib design: ES5 or ES6
14:03:16 <krotscheck> 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 <betherly> o/ sorry im late
14:03:44 <krotscheck> 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 <cardeois> On my side I said last week that using es6 with babel was taking something like 300MB
14:04:07 <cardeois> but with npm3 it's not true anymore
14:04:14 <cardeois> It's like 50MB
14:04:26 <krotscheck> cardeois: NPM3's not packaged with node4,. correct?
14:04:48 <cardeois> possible but you could in an alternative install `npm3` package
14:05:04 <cardeois> then `npm3 install` ... it's not perfect but if size is a matter we could use that
14:05:13 <krotscheck> I'm afraid we can't. The constraints set on us by infra are "use a node LTS release".
14:05:50 <krotscheck> point releases tend to be a bit too volatile.
14:05:59 <cardeois> ok
14:06:15 <cardeois> so maybe vkramskikh know more about it and we could ask him next week
14:06:20 <krotscheck> Yep.
14:06:29 <krotscheck> Having said that though, I was able to successfully transpile, test, and run coverage on an ES6 module.
14:06:47 <cardeois> awesome !
14:06:52 <krotscheck> It's jasmine based, so that's as yet undecided, but the review is here: https://review.openstack.org/#/c/334268/
14:07:33 <yujunz> I'll have a look at them later
14:07:56 <krotscheck> 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 <cardeois> 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 <krotscheck> But it also successfully generates a coverage report for the original ES6 code, which is something I was worried about.
14:08:41 <krotscheck> cardeois: That's a different agenda item :D
14:08:47 <cardeois> alright
14:09:04 <krotscheck> 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 <krotscheck> Alright, we still need vkramskikh to come back with his research on the topic.
14:09:32 <krotscheck> But so far everything looks good.
14:09:34 <krotscheck> Moving on.
14:09:52 <krotscheck> #topic js-openstacklib design: What is server interaction approach
14:10:01 <krotscheck> #link https://review.openstack.org/#/c/333901/
14:10:27 <krotscheck> 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 <betherly> ++
14:10:44 <cardeois> I can try yes
14:10:48 <yujunz> +1
14:10:53 <betherly> i can
14:10:55 <krotscheck> Thank you everyone :)
14:10:59 <msmol> I will as well
14:10:59 <jaranovich> i'm going to participate in the review too
14:11:05 <krotscheck> Please do.
14:11:16 <larainema> me too
14:11:21 <krotscheck> The faster we get these reviewed, the faster we can write code, the faster we can ship :D
14:11:32 <betherly> woot
14:11:49 <krotscheck> (the faster we can put this into js-generator-openstack and autodetect your cloud during the bootstrapping process)
14:11:51 <krotscheck> Next!
14:12:07 <krotscheck> #topick js-openstacklib design: Configuring the library.
14:12:09 <krotscheck> #link https://review.openstack.org/#/c/331801/
14:12:50 <krotscheck> 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 <krotscheck> I'm envisioning something like var api = new OpenStack(config);
14:13:32 <cardeois> What do you mean reading? The parsing of the file?
14:13:37 <krotscheck> Yes.
14:13:42 <krotscheck> And autodiscovery.
14:14:22 <krotscheck> 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 <cardeois> 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 <cardeois> Ok will do
14:14:57 <krotscheck> 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 <krotscheck> More reviews requested on that one.
14:15:23 <krotscheck> Any questions on that one?
14:15:39 <betherly> ill comment if i have any later. for now no :)
14:15:48 <krotscheck> #topic js-openstacklib design: Devstack testing
14:15:55 <krotscheck> #link https://review.openstack.org/#/c/331359/
14:16:01 <krotscheck> Summary: Hey, we should gate against devstack
14:16:13 <tsufiev> good luck with that ;)
14:16:37 <krotscheck> tsufiev: We'd love the help of an experienced horizon dev on how to set that up properly :D
14:17:09 <tsufiev> my jokingly tone was more related to devstack being not very stable sometimes
14:17:16 <tsufiev> but of course, I'm exaggerating here
14:17:25 <krotscheck> tsufiev: We'd love the help of an experienced dev to help make devstack stable :D :D
14:17:33 <krotscheck> Does everyone agree that this is a good thing?
14:17:34 <tsufiev> horizon integration tests recently have been runnign pretty well over devstack
14:17:42 <yujunz> Yes
14:18:17 <krotscheck> 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 <cardeois> I have no idea how to do that, but I can help, or get some help
14:19:30 <jprivard> 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 <krotscheck> 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 <krotscheck> jprivard: Awesome, thanks
14:20:22 <cardeois> alright
14:20:37 <krotscheck> #action cardeois and jprivard to work on creating a dsvm job for js-openstack-lib once the spec is approved.
14:21:08 <krotscheck> 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 <jprivard> noted!
14:21:22 <krotscheck> Moving on
14:21:30 <krotscheck> #topic js-openstacklib design: Node6LTS
14:21:41 <krotscheck> Node 6 has been out since the summit, maybe we should start using it?
14:21:51 <krotscheck> There's come concerns.
14:21:56 <krotscheck> Not everyone uses node6 yet.
14:22:30 <krotscheck> 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 <krotscheck> larainema Any progress on that?
14:23:03 <larainema> yes, I can install node6 on xenial
14:23:17 <krotscheck> larainema WOO!
14:23:23 <msmol> node6 will be the current LTS starting in October. that's only a few short months away
14:23:24 <larainema> but I have no idea how to leveage the old version
14:23:38 <krotscheck> msmol: True, however node4 will continue to live on as long as xenial is the LTS
14:23:47 <tsufiev> would installing node6 break existing npm-based jobs, krotscheck?
14:24:02 <krotscheck> tsufiev: The hope is that the macro will be parameterized with a default of 4
14:24:15 <tsufiev> good to know :)
14:25:06 <krotscheck> 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 <cardeois> 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 <krotscheck> larainema: If you create a patch that just installs node6 instead of 4, we can investigate it together on gerrit.
14:26:03 <krotscheck> cardeois: Well, that's part of the discussion
14:26:36 <larainema> krotscheck, OK, I will do it first
14:26:37 <krotscheck> So the first question is: Should we support node6?
14:26:52 <krotscheck> I'm sure we'd all love to use all the awesome new features.
14:27:10 <krotscheck> But, if our support target is node4, then we still have to transpile, so it might not be worth the effort.
14:27:40 <krotscheck> Personally, shaking things up in Newton may not be a good idea.
14:27:55 <krotscheck> But then we're a new project, so it matters less.
14:28:03 <krotscheck> (It doesn't really matter at all as long as we don't break horizon)
14:28:13 <krotscheck> Thoughts?
14:28:53 <cardeois> True but if we use ES6 anyway is that a problem to transpile?
14:30:03 <yujunz> Is that to be answered in the first topic?
14:30:18 <krotscheck> I think so. We've figured out transpiling.
14:30:31 <krotscheck> Or, well, I've got a draft of it anyway
14:30:50 <yujunz> Even there is no problem, I think it will require some extra effort.
14:30:55 <krotscheck> Since we've decided to be isomorphic, we're deploying to browsers anyway. That means ES5
14:32:04 <krotscheck> Ok, seems like we're not reaching a decision on this one, and few people are engaged in the discussion.
14:32:05 <cardeois> 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 <cardeois> We could report the subject for next week, I'm fine with that
14:33:05 <krotscheck> 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 <krotscheck> 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 <yujunz> Agree to send it to next week
14:34:18 <jaranovich> ++
14:35:07 <krotscheck> Okies, next
14:35:13 <cardeois> krotscheck to answer your question, I don't know...
14:35:36 <krotscheck> #topic js-openstacklib design: Test Framework!
14:36:00 <krotscheck> Before we argue jasmine vs. mocha, does anyone have a problem with istanbul?
14:36:08 <krotscheck> (Code coverage.
14:36:09 <yujunz> No
14:36:33 <krotscheck> 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 <cardeois> Nope good to me if it works well with es6
14:36:48 <yujunz> I'm fine with istanbul
14:36:55 <krotscheck> Excellent.
14:36:57 <msmol> yep looks good
14:37:06 <krotscheck> #agreed istanbul will be used for code coverage.
14:37:26 <krotscheck> So: jasmine vs moca.
14:37:27 <krotscheck> *mocha
14:37:48 <yujunz> I'm more familiar with mocha, but ok with jasmine.
14:37:54 <msmol> 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 <cardeois> As for jasmine vs mocha, for start we need to run tests for browsers AND node directly
14:38:05 <msmol> e.g. sinon
14:38:32 <cardeois> 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 <krotscheck> I'm going to paste something I got in email from notmars
14:39:04 <krotscheck> "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 <krotscheck> This patch runs both browser and node tests: https://review.openstack.org/#/c/334268/
14:39:39 <krotscheck> (using jasmine and karma-jasmine)
14:40:00 <krotscheck> (evidence: http://logs.openstack.org/68/334268/1/check/gate-js-openstack-lib-npm-run-test/6c7e20f/cover/)
14:40:08 <cardeois> 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 <krotscheck> I expect that mocha will basically be the same.
14:40:50 <krotscheck> I disagree that mocha syntax is the same as jasmine though.
14:41:16 <krotscheck> Oh wait, wrong version.
14:41:21 <krotscheck> You're right, syntax is basically identical
14:41:44 <krotscheck> Does anyone know what fuel uses?
14:42:05 <krotscheck> I know that all the other js projects out there (horizon, storyboard, openstack-health) use jasmine.
14:42:19 <msmol> 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 <krotscheck> 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 <krotscheck> And, quite frankly, bikeshedding is the death of open source.
14:43:12 <cardeois> 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 <krotscheck> I'd rather have a monolithic, single dependnecy, and skip all those future arguments altogether.
14:44:21 <krotscheck> Fewer dependencies = fewer moving parts = fewer potential failures.
14:44:31 <cardeois> +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 <jaranovich> no jasmine in fuel dev dependencies
14:44:47 <jaranovich> but mocha is used
14:44:51 <krotscheck> jaranovich: Gotcha.
14:45:02 <msmol> krotscheck: very good point
14:45:02 <krotscheck> jaranovich: Thanks for looking that up.
14:45:28 <krotscheck> One question: Has anyone here ever moved a project from jasmine to mocha, or back?
14:45:41 <yujunz> Never...
14:45:42 <krotscheck> 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 <krotscheck> i.e. cost to change our mind :)
14:46:42 <cardeois> Didn't do it, but if there's external libraries to support jasmine asserts/mocks/etc that might not be hard
14:47:16 <cardeois> But code could be messed up with old/new way to do asserts, which is bad
14:47:26 <krotscheck> timothyb89 might have an opinion, he just wrote karma-subunit-reporter.
14:47:48 <timothyb89> I haven't used mocha, but it does look very similar
14:47:55 <msmol> 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 <timothyb89> I could try rewriting stackviz's tests to try it out :)
14:48:43 <krotscheck> timothyb89: Naah, just trying to get as many people to pay attention to this discussion before I call a vote.
14:48:45 <cardeois> That's actually a good point msmol, you can run mocha tests in jasmine, so transition could be progressive
14:48:58 <krotscheck> :D
14:49:03 <tsufiev> +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 <krotscheck> Ok, talk amongst yourselves, I'm going to go figure out the voting syntax....
14:50:09 <jprivard> talk? Huh, so bothersome
14:50:12 <krotscheck> #startvote Which testing framework should we use? Jasmine, Mocha, Abstain
14:50:12 <openstack> Begin voting on: Which testing framework should we use? Valid vote options are Jasmine, Mocha, Abstain.
14:50:13 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
14:50:36 <cardeois> #vote Jasmine
14:50:38 <jprivard> #vote Jasmine
14:50:55 <krotscheck> #vote Jasmine
14:51:00 <larainema> #vote Jasmine
14:51:01 <timothyb89> #vote Jasmine
14:51:30 <yujunz> #vote Abstain
14:51:39 <msmol> #vote Jasmine
14:51:49 <krotscheck> timothyb89, betherly, yujunz, tsufiev: Opinions? Disagreeing is not looked upon negatively :)
14:51:55 <krotscheck> Oops, nevermind
14:51:58 <krotscheck> need to type faster.
14:52:08 <tsufiev> #vote Jasmine
14:52:21 <betherly> #vote Jasmine
14:52:30 <krotscheck> That's definitely a quorum.
14:52:37 <krotscheck> #endvote
14:52:38 <openstack> Voted on "Which testing framework should we use?" Results are
14:52:39 <openstack> Abstain (1): yujunz
14:52:40 <openstack> Jasmine (8): betherly, timothyb89, krotscheck, cardeois, jprivard, tsufiev, larainema, msmol
14:52:47 <krotscheck> Alright, jasmine it is!
14:52:49 <krotscheck> Moving on.
14:53:11 <krotscheck> #topic Add permanent agenda link to eavesdrop.openstack.org
14:53:23 <yujunz> I proposed it, so I will do it
14:53:29 <krotscheck> Excellent, thanks!
14:53:40 <yujunz> I just forgot the link today and think it would be necessary
14:53:47 <krotscheck> #action yujunz Add permanent agenda link to javascript meeting in openstack-meeting repo.
14:54:01 <krotscheck> #topic Project Dashboard for work tracking.
14:54:07 <krotscheck> How do we want to track work?
14:54:12 <krotscheck> (5 minute warning)
14:54:23 <yujunz> Linked to the agenda issue.
14:54:34 <yujunz> 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 <krotscheck> #action krotscheck Set up a javascript wiki
14:55:14 <krotscheck> From there we can link to StoryBoard, etc.
14:55:22 <krotscheck> #topic Open Discussion
14:55:45 * krotscheck is on vacation starting tomorrow, so will have limited access.
14:56:01 <yujunz> Comments required on IIFE removal
14:56:01 * betherly will be off monday and tuesday to deal with my house move
14:56:05 <yujunz> #link https://review.openstack.org/#/c/335318/
14:57:20 <krotscheck> yujunz: I'm in favor.
14:57:43 <krotscheck> Actually, that begs the question about eslint rules.
14:57:59 <krotscheck> Anyone want to start digging into those and see if we can separate those rules into "node" and "browser"?
14:58:25 <yujunz> I can do it.
14:58:44 <yujunz> I've also encounter issues on eslint version.
14:58:53 <yujunz> 2.4.0 in eslint-config-openstack vs 1.10.3 in js-generator-openstack
14:58:56 <krotscheck> yujunz: Yeah, you can update that whenever you want.
14:59:11 <krotscheck> We don't have automatic dependency synchronization yet.
14:59:30 <yujunz> I would prefer move to 2.x
14:59:37 <yujunz> since this is the default stable version
14:59:59 <krotscheck> yujunz: Go ahead :)
15:00:03 <krotscheck> And we're done!
15:00:06 <krotscheck> Thankss everyone!
15:00:08 <krotscheck> #endmeeting