| rick_h_ | morning party people | 12:04 |
|---|---|---|
| luca | frankban: Hey, Sorry for not replying yesterday, I was sidetracked when you asked me a question, did you need anything from me? | 13:05 |
| frankban | luca: doing something different now, I was asking about how the sidebar message should be hidden: once per session, per model or once forevere | 13:07 |
| luca | frankban: I think it should be once per model for the time being | 13:08 |
| luca | frankban: though I can imagine it getting really annoying quite fast lol | 13:08 |
| luca | frankban: though it would be good to test | 13:08 |
| frankban | luca: ok, good to know, could you add this info to the bug? | 13:08 |
| luca | frankban: sure | 13:08 |
| frankban | thanks | 13:09 |
| rick_h_ | Makyo: or frankban can you do a second review of https://github.com/juju/juju-gui/pull/623 qa already done | 13:54 |
| frankban | rick_h_: sure | 13:54 |
| rick_h_ | ty frankban | 13:54 |
| kadams54 | On my way to the dentist. May not be back in time for standup. | 14:20 |
| rick_h_ | kadams54: rgr | 14:20 |
| rick_h_ | kadams54: let's sync up when you get back then | 14:21 |
| hatch | jrwren: when we were ragging on Go syntax yesterday you said that it was because the gcc compiler is slow so we need to help it - do you have any references for that? | 14:22 |
| jrwren | hatch: one of Rob Pike's early go presentations. I think from google io 2010 | 14:26 |
| hatch | ohh yeah I remember that one - unfortunately he doesn't give any examples | 14:26 |
| jrwren | sure he did. | 14:26 |
| hatch | did he? | 14:27 |
| hatch | hmm | 14:27 |
| jrwren | he said they have C++ projects which take minutes or into the hours to compile and the same thing in go is seconds. | 14:27 |
| hatch | right - but how does the ugly syntax have anything to do with that | 14:27 |
| jrwren | hatch: maybe we think different thing are ugly? | 14:27 |
| jrwren | hatch: the language was designed wiht parsing and compilation as a top concern, hence, ugly syntax to help the parser be fast. | 14:28 |
| jrwren | I swear he went into some details, but admittedly parsing is pretty fast and easy. Its more the package reference system that speeds it up. | 14:29 |
| hatch | yeah | 14:29 |
| hatch | maybe my issue with the syntax is gofmt | 14:29 |
| hatch | if I have to horizontally scroll github....the line is too long ;) | 14:29 |
| jrwren | oh! I totally agree. we should still follow 79 column limit. | 14:33 |
| jrwren | but that is a nit. | 14:33 |
| jrwren | Do you follow that in js? | 14:33 |
| rick_h_ | jrwren: yes | 14:33 |
| rick_h_ | jrwren: I think the only exception is html and that we try hard to but sometimes the nesting goes too far where it's less readable | 14:34 |
| jrwren | you can't exactly extract a function in html to fix that. | 14:34 |
| rick_h_ | right | 14:35 |
| rick_h_ | so we're a bit more lenient on that side, but there will still be review comments sometimes to indent/break up the html a bit | 14:35 |
| hatch | rick_h_: so when doing a charm with deploy-target it needs to be comitted and the machine auto placed? | 14:48 |
| rick_h_ | hatch: yes | 14:48 |
| rick_h_ | jujugui call in 8 kanban please | 14:54 |
| rick_h_ | Makyo: standup? | 15:00 |
| hatch | jujugui have we ever programatically auto-committed anything from the browser.js portion of the app? The deployer bar doesn't appear to be passed into the browser.js nor can I find any events | 15:17 |
| rick_h_ | hatch: don't think so. The times we've had to communicate like that we've event chained up through app and down into browser like the inspector "page takeover" event stuff | 15:18 |
| rick_h_ | hatch: does it have to happen from browser.js? Can it not just be from state? | 15:18 |
| hatch | browser.js is the only component which handles the state dispatches | 15:18 |
| hatch | but the deployer bar is rendered in the app.js | 15:18 |
| hatch | I can fire an event from browser.js and listen in app.js | 15:19 |
| hatch | just didn't want to duplicate work | 15:19 |
| rick_h_ | hmmm, yea I think that'd be the best path | 15:19 |
| rick_h_ | off the top of my head | 15:19 |
| hatch | state instantiation should probably be moved into the app layer | 15:19 |
| hatch | buuuuuuut | 15:19 |
| hatch | yeah | 15:19 |
| hatch | no | 15:19 |
| hatch | :P | 15:19 |
| rick_h_ | hah, one thing at a time. | 15:19 |
| hatch | Makyo: bring me back some good beers! | 15:26 |
| hatch | oh wait.... | 15:26 |
| hatch | :P | 15:26 |
| Makyo | I think we've got better beer in Colorado, personally, but I'm biased. | 15:29 |
| hatch | only a little :) | 15:30 |
| hatch | plus I'm not sure if CA has any water to make beer | 15:30 |
| hatch | boo yeah, charms deploy | 15:35 |
| hatch | jrwren: grep for switch :'( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let | 15:37 |
| jrwren | hatch: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-switch-statement-static-semantics-lexicallyscopeddeclarations | 15:44 |
| hatch | well then... | 15:44 |
| hatch | give it time | 15:45 |
| hatch | they have time to wreck it yet | 15:45 |
| hatch | :P | 15:45 |
| jrwren | hatch: This is why having beers is good. I had beers with semjs group last Monday and learned about exactly this :) | 15:46 |
| hatch | I am really not sure why we can't have more 'statement switches' like 'use strict' to avoid javascript turning into php with run away operators | 15:47 |
| hatch | 'use strict bools' 'use lexical scope' ex | 15:47 |
| jrwren | hatch: I said the same thing. I got a reasonable answer, but I don't recall what it was. | 15:47 |
| hatch | they will break with old browsers | 15:48 |
| hatch | so yes actually i am sure I know why - not that I agree :) | 15:48 |
| hatch | it's purely acceptable to have your page break on certain browsers if they don't support certain features | 15:49 |
| hatch | s/purely/perfectly | 15:49 |
| jrwren | hatch: not to mention, i was told there are compilers to go to ES3 to target old browsers. | 15:51 |
| hatch | yeah they are not perfect but they do exist | 15:52 |
| hatch | jrwren: https://twitter.com/FromAnEgg/status/524589297643835393 maybe I'll get a real answer :) | 15:53 |
| jrwren | hatch: that page doesn't exist. | 15:54 |
| arosales | rick_h_: in the readme for bundles | 15:55 |
| hatch | oops sorry I had to fix a typo, thought it would just update it https://twitter.com/FromAnEgg/status/524589600879411201 | 15:55 |
| arosales | luca would like more human readmable bundle name | 15:55 |
| hatch | finally! | 15:55 |
| lazyPower | hatch: *eyeballs suspiciously* | 15:55 |
| hatch | lazyPower: wutulookinat?? | 15:56 |
| hatch | willis | 15:56 |
| lazyPower | i'mlookinatyouethel | 15:56 |
| hatch | wutulookinatwillis | 15:56 |
| arosales | rick_h_: so my question is you mentioned in the new charm store you would be able to parse more metadata | 15:58 |
| arosales | what are those fields, can we assume the same as charms? | 15:58 |
| arosales | if same as charm does the name field have to match the parent directory? | 15:58 |
| hatch | lazyPower: did you see http://techcrunch.com/2014/10/20/crate-lets-developers-set-up-big-data-backends-in-minutes/ | 15:59 |
| rick_h_ | arosales: description and tags right now | 16:00 |
| rick_h_ | arosales: if we need more we can work on that | 16:00 |
| === alexpilotti_ is now known as alexpilotti | ||
| * hatch waves at teslanick | 16:07 | |
| lazyPower | hatch: that'll generate some buzz, i'll be watching this closer | 16:08 |
| lazyPower | hatch: we saw a fwe other companies presenting similar tech @ hadoop world that go as far as dropping a slick dashboard on top of it when you're done | 16:08 |
| hatch | lazyPower: I was thinking we should respond with a blog post *caugh* onyourblog *caugh* | 16:08 |
| hatch | cough even | 16:08 |
| lazyPower | hatch: what i see as a problem with this - is it has an end of the sidewalk effect with your deployment tooling | 16:08 |
| hatch | yeah I agree | 16:08 |
| lazyPower | as you only deploy/scale your big data stack with it, which segments your deployment tooling | 16:08 |
| hatch | but they are getting at least a bit of traction | 16:09 |
| lazyPower | using juju you could wrap this and get teh best of the universe | 16:09 |
| lazyPower | but i dont want to chase buzz - i want to chase solutions. If this gets any kind of adoption i'll respond with a bundle that wraps crate, because its *so* easy to use, they claim. Shouldn't take more than a few weeks to charm up. | 16:09 |
| lazyPower | hatch: i'm already scheduled this week to interview hazmat and talk about his rudder/flannel density story + an emerging kubernetes story next week | 16:10 |
| lazyPower | and as far as i can tell that'll attract a lot of attention because... docker docker docker | 16:10 |
| hatch | I don't really see the point of kubernetes with juju | 16:10 |
| hatch | but that's just me | 16:10 |
| lazyPower | buzzword/buzzfeed | 16:10 |
| lazyPower | inb4 google announcement | 16:11 |
| hatch | lol | 16:11 |
| lazyPower | google compute engine + kubernates = "the future of now" according to some. | 16:11 |
| * hatch rolls eyeballs into neck | 16:11 | |
| hatch | that's how far they rolled back....right into my neck!! | 16:11 |
| lazyPower | personally, i'm kind of sick of hearing about docker and how a delivery mechanism is going to make everything amazing. I still think a hybrid CM+IBW = the winner. There's enough out there you just *dont want* to image up and ship as immutable. | 16:12 |
| jrwren | hadoop is over for 99% of its use cases now that azure launched their G-series. Just run it on a Standard_G5 :p | 16:12 |
| lazyPower | but thats me and my opinions again | 16:12 |
| lazyPower | jrwren: actually the prediction of hadoop is its going to 'go away' - and turn into invisible plumbing that nobody talks about anymore | 16:13 |
| jrwren | lazyPower: i'm sick of hearing about hadoop & docker, but... yeah, opinions :) | 16:13 |
| lazyPower | now that off teh shelf solutions are starting to mature on top of hadoop. | 16:13 |
| jrwren | lazyPower: its still a waste. avoid the jvm. | 16:13 |
| lazyPower | jrwren: java = enterprise. Good luck winning that battle. | 16:13 |
| lazyPower | its like trying to convert a .net shop into a ruby shop ;) | 16:14 |
| lazyPower | it can be done, but its uphill both ways | 16:14 |
| jrwren | lazyPower: didn't you already do that? :) | 16:14 |
| lazyPower | ^ | 16:14 |
| jrwren | lazyPower: why go backwards like that? :) | 16:14 |
| lazyPower | My eyes opened to so much @ hadoop world | 16:14 |
| jrwren | lazyPower: oh no, drinking the kool-aide? | 16:14 |
| jrwren | lazyPower: did you write a report? | 16:14 |
| lazyPower | it cracks me up that people vendoring stuff @ the conf still have no idea what 'big data' really is. | 16:14 |
| hatch | jrwren: rofl | 16:15 |
| lazyPower | jrwren: sure did, sent it out the first day. it's on canonical-tech and clodus | 16:15 |
| lazyPower | *clouds | 16:15 |
| hatch | oh I read that as a joke on enterprise and writing reports :D | 16:15 |
| hazmat | hatch, its like openstack or any other platform for workloads.. | 16:15 |
| hazmat | hatch, part of the story there is going into the docker community, and being like hey.. dog.. i heard you like orchestration frameworks ;-) | 16:15 |
| jrwren | lazyPower: ah, I read that. I didn't read too much koolaide in it. | 16:15 |
| hazmat | hatch, a little more seriously they have dozens.. and we can position juju as the easy way to collect/try them all | 16:16 |
| lazyPower | jrwren: because i didn't drink it. i challenged what they were telling me and found there's more just under the surface | 16:16 |
| hazmat | s/dog/dawg | 16:16 |
| hatch | hazmat: right, but why use any of them at all and instead just use juju? | 16:16 |
| lazyPower | hazmat: did you read my response to crate? thats how i'm looking at all of this IBW buzz - we're gonig to find the sweet spots and enable them | 16:16 |
| lazyPower | i'm working a pittsburgh client to upgrade their chef-server opscode hosted infra to juju powered chef-solo charms. | 16:17 |
| lazyPower | give me anotehr month and i bet i have them in our pocket | 16:17 |
| hazmat | hatch, because they do more things than we do wrt to some aspect of a workflow.. or because their docker centric instead of charm centric.. docker image authoring is falling off a log.. good charm authoring.. a bit harder. | 16:17 |
| arosales | rick_h_: sorry, my network got dropped | 16:17 |
| hatch | hazmat: true true | 16:18 |
| hazmat | hatch, ie. kubernetes will do round robin image upgrades etc, and persistent storage. | 16:18 |
| rick_h_ | arosales: description and tags right now, we can do more if needed | 16:18 |
| arosales | rick_h_: I think we talked about author and name | 16:18 |
| arosales | or at least author | 16:18 |
| lazyPower | rick_h_: was thsi outlined in that doc you sent me @ brussels? | 16:18 |
| lazyPower | i'll read the spec and update our bundles accordingly | 16:18 |
| arosales | as they branch owner is not always the author/maintainer | 16:18 |
| rick_h_ | lazyPower: yes | 16:18 |
| lazyPower | <3 ty for giving me more info than i knew i needed early | 16:18 |
| hatch | hazmat: yeah those are two features we would be nice to have | 16:18 |
| arosales | rick_h_: good example is ~charmers | 16:18 |
| arosales | right now the charm store is calling ~charmers the author/maintainer when in fact that is not correct | 16:19 |
| rick_h_ | arosales: right, that's part of juju publish | 16:19 |
| arosales | and currently pulling the name from the directory structure too | 16:19 |
| lazyPower | what the... can anyone else get to google drive atm? mine is throwing errors at me | 16:20 |
| lazyPower | rick_h_: we're going to see juju publish 1q of next year right? or is that coming sooner? | 16:20 |
| arosales | rick_h_: I think regardless of publish though the bundle should state who is the author/maintainer | 16:20 |
| hatch | definitely - i've always hated that with ~charmers | 16:21 |
| lazyPower | arosales: sending you a link to the bundle spec in private | 16:21 |
| arosales | rick_h_: we'll run into the same problem with publish when a charmer "reviews" a charm | 16:21 |
| arosales | lazyPower: still dont' see author or name in that spec | 16:23 |
| lazyPower | rick_h_: if its buried in the struct code, i'm too ignorant to parse it out. where do we define this? | 16:23 |
| jrwren | apache-spark... because 138MB jar files are awesome. *sigh* | 16:24 |
| lazyPower | jrwren: then use HPCC | 16:24 |
| jrwren | lazyPower: i don't know anything about this stuff. I only know I don't like it :p | 16:24 |
| lazyPower | jrwren: you're not the data scientist target for these tools ;) | 16:25 |
| jrwren | brew search hpcc says no formula. it doesn't exist :p | 16:25 |
| jrwren | lazyPower: data scientists aren't the target for these tools either. | 16:25 |
| lazyPower | jrwren: http://hpccsystems.com/ | 16:25 |
| lazyPower | i beg to differ | 16:25 |
| hatch | jujugui could I get a wip review before I go fix/write all the tests on the deploy-target stuff https://github.com/juju/juju-gui/pull/624/files | 16:26 |
| rick_h_ | arosales: lazyPower otp atm back in a sec | 16:27 |
| lazyPower | ack | 16:27 |
| rick_h_ | arosales: yes, we talked about that in brussels. We need to get work done to not call the ~charmers the author/maintainer and it's part of fugure work and won't be available for the release next week | 16:31 |
| rick_h_ | arosales: putting anything in the bundles.yaml is just like metadata.yaml. It lies on first fork and so we don't trust it and we have a path to a better way but it's work to do | 16:31 |
| rick_h_ | lazyPower: yes, it's on the todo starting in Nov | 16:31 |
| rick_h_ | lazyPower: we'll get docs updated in the bundles docs here shortly. As we're working towards the release next week, docs are always last sorry | 16:32 |
| rick_h_ | lazyPower: but adding a card to update bundle docs for our post-release updates to do | 16:32 |
| lazyPower | arosales, rick_h_: so what i'm parsing from our conversation is that we're not ready for me to just stuff in metadata, and should work towards a solution that 'works today' and monitor this story as it emerges? | 16:32 |
| arosales | lazyPower: ya for luca's charm store lauch it sounds like the new bundle format with any meta data won't be available. | 16:33 |
| rick_h_ | lazyPower: correct, new fields in metadata need to be 100% good across forks (like tags/description) and any more we need we can support. However, the authoship problem is a bigger problem with a known solution that's planned in work upcoming in Nov | 16:33 |
| lazyPower | that will satisfy luca's needs, and get us 3/4 of the way for when the new bundle spec lands - when we can update with a complete spec | 16:33 |
| lazyPower | ok. Thanks for the heads up rick_h_ | 16:34 |
| rick_h_ | arosales: the new bundle format is available for launch, just not the owner stuff. The placement updates need an update to deployer as well that'll be part of that follow up work. | 16:34 |
| arosales | rick_h_: but we should certainly add the maintainer field and name to the bundle metadata (weather that lives in the bundles.yaml or someplace else I leave to the implementors) -- do you agree? | 16:35 |
| rick_h_ | arosales: the idea is that with identity that's automatically figure-out-able other than the promulgated in which case we allow charmers to specify during the cli to promulgate something | 16:35 |
| rick_h_ | arosales: lazyPower let me know if jumping on a hangout would help explain this better | 16:36 |
| lazyPower | rick_h_: i think it would settle this up quicker | 16:36 |
| lazyPower | arosales: do you have time to join or do you want me to spear head this and re-educate at standup? | 16:36 |
| arosales | lazyPower: sorry I may have missed a invite, join which meeting? | 16:38 |
| arosales | rick_h_: but that doesn't live in source | 16:38 |
| rick_h_ | arosales: yes, that's what we want. For it to not live in the source code. | 16:38 |
| arosales | rick_h_: and we still have a naming issue, specifically where do we pull a bundle name from? | 16:39 |
| kadams54 | rick_h_: Back, though the left side of my face is numb :-\ | 16:39 |
| arosales | rick_h_: well my feedback is the author name should live in source in the metadata.yaml | 16:39 |
| rick_h_ | arosales: huh? what's the issue with that? | 16:39 |
| arosales | not just in the store | 16:39 |
| arosales | name currently just gets pulled from the dir structure, correct? | 16:39 |
| rick_h_ | arosales: and our feedback on that is that having it in the source code, unless we go in and update it on the fly, tells users completely false information. | 16:39 |
| rick_h_ | arosales: no, the bundle has a name in the top of the yaml format | 16:40 |
| rick_h_ | arosales: but we agreed that when we download it we'll name the zip/directory created with the bundle name | 16:40 |
| arosales | rick_h_: ok. I think luca may be pulling the dir name . . . we should confirm on that but agree the bundle top-level should be the correct name. | 16:40 |
| rick_h_ | arosales: https://manage.jujucharms.com/api/3/bundle/~charmers/mongodb/5/cluster/file/bundles.yaml 'cluster' is the name | 16:41 |
| rick_h_ | arosales: +1 | 16:41 |
| arosales | rick_h_: agreed in manage, but looks different on new-jujucharms qa site | 16:41 |
| rick_h_ | arosales: link? | 16:42 |
| arosales | rick_h_: take it fwiw but I really feel in-source we should have the author named specifically | 16:42 |
| arosales | just to try to get attribution correct when downloading source | 16:43 |
| arosales | unless you ae going to inject that somehow when folks download | 16:43 |
| rick_h_ | arosales: so for every upload of the bundle, at the top, you want to put the 'owner' as the source in that file? | 16:43 |
| rick_h_ | arosales: if it has to be in the source like that I'd just propose we have a server generated CONTACT or OWNER document that we do on download/etc | 16:43 |
| lazyPower | rick_h_: i'm missing the purpose of de-coupling this information... and i apologize if you've already covered this. | 16:44 |
| rick_h_ | lazyPower: arosales https://plus.google.com/hangouts/_/gyt4mcw4h3dci67wr243sbdkaea?authuser=1&hl=en | 16:44 |
| lazyPower | when we say identity thats auto-figure-outable - is this so juju publish stamps the charms you push? | 16:44 |
| hatch | jujugui still looking for someone to take a look at this wip https://github.com/juju/juju-gui/pull/624 | 16:54 |
| kadams54 | hatch: I'll take a look | 16:54 |
| hatch | thanks | 16:54 |
| hatch | coding is done, working on tests now - but would rather catch any oddities before I finish these tests :) | 16:55 |
| lazyPower | rick_h_: quick question about current store display - did this meet some kind of wrapping line length to shift display? https://jujucharms.com/bundle/~lazypower/big-data-logger/4/hortonworks-logging-demo/?text=hdp | 17:08 |
| rick_h_ | lazyPower: it just didn't fit, it's wrapped bug below the icon image | 17:09 |
| lazyPower | http://i.imgur.com/uufBi9P.png - is what i see. and it looks like wrapping. | 17:09 |
| rick_h_ | lazyPower: right, it is too long to fit between the icon and the deploy button | 17:09 |
| lazyPower | thats what i figured. Ok - ta. new store display will make this go away. | 17:09 |
| rick_h_ | lazyPower: we should trunkcate it I guess. | 17:09 |
| rick_h_ | lazyPower: well, it will in teh store but not the GUI | 17:09 |
| lazyPower | oooo | 17:09 |
| lazyPower | good point | 17:09 |
| lazyPower | i'll file a bug report | 17:09 |
| rick_h_ | +1 | 17:09 |
| rick_h_ | thuogh I'm nervous about truncating as well as many bundles might start out with less important text, guess we should try to auto shrink the font size or something better | 17:10 |
| lazyPower | https://bugs.launchpad.net/juju-gui/+bug/1383816 | 17:10 |
| mup | Bug #1383816: line wrapping alters bundle name display <juju-gui:New> <https://launchpad.net/bugs/1383816> | 17:10 |
| hatch | eww that's ugly | 17:12 |
| * rick_h_ goes to find some lunch now, biab | 17:17 | |
| kadams54 | hatch: just finished looking over https://github.com/juju/juju-gui/pull/624 - everything looks good. | 17:58 |
| hatch | kadams54: thanks | 18:03 |
| kadams54 | guihelp: is there any easy way to snag all unrelated services (i.e., deployed services that are NOT related to a given serviceName)? | 18:54 |
| hatch | kadams54: at the moment I don't think there is an inverse method for that | 18:55 |
| kadams54 | hatch: kthnx | 18:55 |
| hatch | you could use the related services method and then take the ones which it doesn't return | 18:55 |
| hatch | might be the easiest | 18:56 |
| hatch | rick_h_: after looking at using immediate: true it doesnt really get us any further because then i'd have to create the machine and place the unit on it anyways | 18:59 |
| hatch | so it's 6/1 6/12 of another | 18:59 |
| rick_h_ | hatch: right, ok that's what I figured. at the start I had hoped it would be useful here | 18:59 |
| hatch | yeah I had blanked on it and thought MAYBE we'd get lucky :) | 19:00 |
| jrwren | lol @ 6/1 | 19:01 |
| hatch | haha u like that? | 19:01 |
| hatch | jrwren: rick_h_ wow your govt is corrupt too http://jalopnik.com/michigan-governor-signs-anti-tesla-bill-into-law-1648978048 | 19:08 |
| kadams54 | hatch: yeah, can't say it's all that surprising in a state that's home to the Big Three. | 19:11 |
| hatch | from an outsider these ban's seem very anti-usa | 19:12 |
| hatch | being such a pro capitalism country and all | 19:12 |
| jrwren | too? | 19:13 |
| hatch | jrwren: along with every other state that's banned it | 19:13 |
| jrwren | hatch: the USA is super corrupt. Every politician is bought and paid for by special interests. | 19:13 |
| jrwren | hatch: oh, Michigan. Yes, them too. | 19:13 |
| kadams54 | jrwren: I'd say our corruption levels are on par with most of the world ;-) | 19:13 |
| hatch | oh i thought you were in michigan jrwren | 19:14 |
| jrwren | hatch: I refuse to say 'us'. | 19:14 |
| hatch | ohh lol | 19:14 |
| jrwren | hatch: i didn't vote for these jerks. | 19:14 |
| kadams54 | hatch: you find that sort of ideology kind of goes out the window when special interests (i.e. the people who vote you into office) come into play. | 19:14 |
| kadams54 | hatch: "I'm for small, efficient government! Just don't close the military base in my home state." | 19:15 |
| hatch | lol | 19:15 |
| hatch | this tesla thing is just baffling though | 19:15 |
| jrwren | The law is almost certainly unconstitutional under the interstate commerce clause, but this is law until it is challenged. | 19:15 |
| hatch | if they had franchise dealerships then it would be ok? It doesn't make any sense | 19:16 |
| hatch | who cares who owns the dealership | 19:16 |
| kadams54 | hatch: What's baffling? It's the old guard protecting the status quo. | 19:16 |
| kadams54 | That's what the old guard always does. | 19:16 |
| hatch | kadams54: true but if I moved to michigan and opened a tesla dealership then it would be ok? | 19:16 |
| hatch | (assuming tesla would do that) | 19:16 |
| kadams54 | Yeah, I think so. Tesla wouldn't do that, but yes. | 19:17 |
| kadams54 | The best option Tesla has is to sell a buttload of cars in non-restricted states | 19:17 |
| kadams54 | Depriving the restricted states of tax revenue | 19:17 |
| hatch | right so if that's the case then I don't see how this changes anything | 19:17 |
| jrwren | gas prices are so low now, who wants a tesla? I'll stick with a vette :p | 19:17 |
| hatch | Elon could just open up a dealership chain of tesla dealers | 19:18 |
| hatch | that's not owned by tesla | 19:18 |
| hatch | essentially skirting the bs law | 19:18 |
| kadams54 | Yeah, I have no clue what sort of corporate shennanigans are possible. | 19:18 |
| hatch | so this is why it's baffling, I dont' see how anyone benefits from this ban - if only to delay the inevitable | 19:19 |
| kadams54 | I know Gordon Food Service's trucks were leased to GFS by another company, which was also owned by the Gordon family. The whole thing was to limit GFS' liability in case of an accident. So those sort of things do happen. | 19:19 |
| hatch | oh yeah for sure - tons of airlines are actually many small companies being hired by the big ones | 19:20 |
| hatch | to do the same | 19:20 |
| kadams54 | Dragged kicking and screaming into the 21st century. | 19:20 |
| hatch | lol | 19:20 |
| kadams54 | hatch: Ok, I'm not finding a related service method. | 19:21 |
| hatch | kadams54: hmm it definitely exists because that's how it knows what it can relate to | 19:21 |
| kadams54 | I'm pretty sure one exists and I'm pretty sure I've seen it used elsewhere, but my ack skills are not turning up anything. | 19:22 |
| kadams54 | I'll poke around in code | 19:22 |
| hatch | well doesn't the 'fade service' use it? | 19:22 |
| hatch | that fades the service and it's relation lines | 19:22 |
| kadams54 | utils.getRelationDataForService() is the winner. | 19:23 |
| hatch | there we go | 19:23 |
| kadams54 | hatch: for highlight, we need to fade all unrelated services, in addition to highlighting the selected service and its relations. | 19:23 |
| hatch | ohh ok | 19:24 |
| hatch | that's interesting | 19:24 |
| urulama | jujugui: anyone needing mycomiclife CS running? I see some activity ... can it go down for 5min? | 19:34 |
| rick_h_ | kadams54: did that branch get up for WIP eyeballs? | 20:53 |
| kadams54 | rick_h_: not yet… hit a dead end, had to backtrack, getting close again. | 21:27 |
| huwshimi | Morning | 22:02 |
| kadams54 | huwshimi: morning | 22:06 |
| huwshimi | kadams54: Hey :) | 22:06 |
| hatch | hey huwshimi | 22:07 |
| huwshimi | hatch: Hey | 22:07 |
| kadams54 | Whoa. Google Canary: if you long click on the reload button, a menu pops up that lets you choose which type of reload you want to do. | 22:14 |
| kadams54 | Normal Reload, Hard Reload, or Empty Cache and Hard Reload. | 22:15 |
| hatch | nice | 22:20 |
| hatch | stepping away for a bit, I'll bbl to get this branch finished and up for review | 22:21 |
| kadams54 | guihelp: https://github.com/juju/juju-gui/pull/625 needs QA. Right now the code is a mess, which is why it's a WIP, so just stick to the QA. | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
