| gary_poster | hey benji, thanks for the report. frankban and teknico are out this week, so it is all North America to get this done. (1) could you give me more details on manage.jujucharms.com being down yesterday? I didn't hear anything else about it, and that's a big deal (if not directly related to the release issues). (2) Was Makyo helping you yesterday? | 12:16 |
|---|---|---|
| rick_h | gary_poster: I talked with benji about it. Going back in revisions caused the code to try to use a deprecated api endpoint | 12:17 |
| benji | sure... | 12:17 |
| rick_h | gary_poster: I'm working on a branch currently that displays a 410/deprecation message for that going forward. | 12:17 |
| benji | yep, the only thing that was down was the old version of the API that is no longer being served | 12:17 |
| benji | (we should consider making the GUI dev environment self-sufficient) | 12:18 |
| gary_poster | rick_h, benji, ah excellent. that one is off the list of worries then :-) | 12:18 |
| benji | :) | 12:18 |
| benji | I should have followed-up that email. | 12:18 |
| rick_h | benji: yea, we went back/forth on running a local charmworld instance before but hadn't hit a real need. http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/index.rst is the getting started guide for it. | 12:19 |
| gary_poster | yeah, charm world needs to be very reliable and highly available so the only driver I have for work like that is off-network development | 12:20 |
| rick_h | gary_poster: right, the trouble is that as we change things the data format gets tied to the api versioning and it causes issuse when you want to go back in time like this | 12:20 |
| gary_poster | benji, was Makyo available to help you with #2 and #3 from my email yesterday | 12:21 |
| gary_poster | rick_h, ack. the only issue there is time, I think | 12:21 |
| rick_h | well, in this case it's more we've been trying to de-couple the data format from the api data presented but anyway... | 12:21 |
| benji | gary_poster: he was available, but we didn't work together on it; I had a bit of a communication fail and didn't reallize there was anything critical to do until about lunch time so I only had time to work on the drag and drop issue and do the binary search as far as I got | 12:23 |
| gary_poster | benji, ok thanks. I think getting him involved may be faster and more productive than the binary search at least for the relation lines issues. I'm not sure what the best approach is for the config issue | 12:24 |
| gary_poster | maybe binary | 12:24 |
| gary_poster | I have two meetings this morning before daily call | 12:25 |
| gary_poster | and I have to get a document about bundles finished this week, which means today and tomorrow, and ideally finished today | 12:25 |
| gary_poster | so I'll be primarily focusing there | 12:25 |
| rick_h | gary_poster: is this 'config' issue that dragging a charm to 'deploy' it doesn't open the config in the right panel for the charm? It was working for me on uistage yesterday. | 12:25 |
| benji | that sounds fine with me; once he is available I'll work with him on it, until then I'll finish up the search for the introduction of the two bugs | 12:25 |
| gary_poster | rick_h, from benji's email: "I also noticed what seems to be a | 12:26 |
| gary_poster | bug in that the config panel is not displayed when deploying the | 12:26 |
| gary_poster | service." | 12:26 |
| gary_poster | I hadn't seen that either. can try to dupe | 12:26 |
| rick_h | gary_poster: right, I guess I'm asking "is config panel the config panel I think it is?" | 12:26 |
| gary_poster | heh | 12:27 |
| rick_h | ok, well if others are unable to dupe maybe I'm following along ok. | 12:27 |
| gary_poster | good question rick_h, maybe that's a question for benji. like I said I will try to dupe. I interpreted it as the pre-inspector config panel | 12:27 |
| rick_h | because I know we've fixed that config panel on deploy twice now. | 12:27 |
| gary_poster | yeah | 12:27 |
| rick_h | and I did it last time so threw me off that it wasn't working | 12:27 |
| gary_poster | was thinking we must not have tested that properly :-/ | 12:28 |
| gary_poster | unit I mean | 12:28 |
| benji | yep, I was referencing the "old" config panel | 12:28 |
| gary_poster | k | 12:28 |
| gary_poster | will try to dupe | 12:28 |
| gary_poster | benji I had to hard reload the browser, then it worked fine | 12:32 |
| gary_poster | the config panel I mean | 12:32 |
| gary_poster | benji, well, the sizing is broken :-( | 12:32 |
| gary_poster | but it shows | 12:33 |
| gary_poster | wait a sec | 12:33 |
| gary_poster | sometimes does sometimes doesn't? | 12:33 |
| benji | good stuff | 12:33 |
| gary_poster | benji, it is broken after a DND | 12:33 |
| gary_poster | but works after an Add button | 12:33 |
| benji | interesting; I'll try the same | 12:34 |
| gary_poster | benji, I suspect this has something to do with translating the charm info | 12:34 |
| rick_h | gary_poster: benji ok, does DND not go through the same deploy event maybe? There's a tweak needed when creating a Charm model instance from a BrowserCharm | 12:34 |
| benji | it could | 12:34 |
| rick_h | it's in the event for the deploy button | 12:34 |
| gary_poster | rick_h, benji, yeah hatch was saying something about this | 12:35 |
| benji | rick_h: on trunk, no it does not; that is one of the changes my review fixes branch will include | 12:35 |
| rick_h | http://paste.mitechie.com/show/976/ | 12:35 |
| rick_h | benji: ah ok. Yea, if options aren't mapped to 'config' then it won't show all the config fields to edit | 12:35 |
| benji | it is odd though, because I am seeing the same behavior in pre-DND versions of trunk | 12:36 |
| rick_h | benji: yea, it was broken for a little bit and I fixed it in the last couple of weeks | 12:36 |
| rick_h | benji: which is why I was surprised it wasn't working :/ | 12:36 |
| rick_h | but that was through the add button since it was pre-dnd | 12:36 |
| rick_h | #1190265 to be exact | 12:38 |
| _mup_ | Bug #1190265: adding a service does not load all config <charmbrowser> <juju-gui:Fix Released by rharding> <https://launchpad.net/bugs/1190265> | 12:38 |
| gary_poster | benji, specifically to dupe, you need to *first* DND with a given charm. Subsequently, all deployments of that charm, including with Add, don't work. conversely, if you start with Add, DND will work. Also, switching to messing with another charm resets. | 12:38 |
| rick_h | gary_poster: I'd imagine that the charm model is cached and is missing the config attribute | 12:38 |
| gary_poster | rick_h, yeah, figured it would be something like that | 12:39 |
| rick_h | gary_poster: so any other work around that model will fail | 12:39 |
| benji | gary_poster: that makes sense; thanks for the info | 12:39 |
| gary_poster | welcome | 12:39 |
| gary_poster | Makyo, hi. when you get in I'd like to know if you have a task in allhands now. If you do, please go ahead and fill those in and we can do the signing dance | 13:26 |
| gary_poster | hatch, you might also have your issues resolved in allhands. Could you verify, and if everything is ok, also enter your goals? | 13:26 |
| gary_poster | (when you get in :-) ) | 13:26 |
| rick_h | adeuring: r=me | 13:50 |
| rick_h | jcsackett: looking over yours now | 13:50 |
| adeuring | rick_h: thanks! | 13:50 |
| hatch | morning | 13:54 |
| hatch | gary_poster: alright I'll check it out | 13:54 |
| gary_poster | morning hatch, thanks | 13:54 |
| rick_h | jcsackett: lgtm with inbound notes. | 13:55 |
| hatch | gary_poster: allhands done! (hopefully correctly this time) :) | 14:16 |
| gary_poster | great thanks hatch, will look soon :-) | 14:17 |
| hatch | rick_h: woah you bought a book on dead trees??? ;) | 14:21 |
| rick_h | hatch: yea, programming reference material doesn't work great on 6" digital form factors imo | 14:21 |
| hatch | haha nope it doesn't | 14:21 |
| benji | Makyo: are you in? | 14:22 |
| Makyo | benji, yep. | 14:22 |
| benji | Makyo: we should work on the relation line offset issue, when you are available | 14:23 |
| Makyo | benji, wrt service menus? | 14:23 |
| Makyo | gary_poster, submitted. | 14:24 |
| gary_poster | yay, thanks Makyo :-) | 14:24 |
| benji | I don't understand the question. They are initiated by the service menu... | 14:24 |
| gary_poster | benji, he's talking about #3 on my original email | 14:24 |
| * benji re-reads. | 14:25 | |
| Makyo | benji, the service menu has been removed for OSCON under the serviceInspector flag to bypass that. It is a problem that needs to be fixed, but it'd be good to prioritize with other inspector panels. | 14:25 |
| benji | Makyo: oh, nope, this is without any flags | 14:26 |
| gary_poster | sinzui, rick_h, I notice that download counts are currently absent in the charm browser. I know there's been some work here. Is that a known issue? | 14:30 |
| jcsackett | rick_h: agree that it would be better to land it with the flag, but i wanted eyes on it now. i can delay landing if sinzui sees no problems with that in our workflow. | 14:31 |
| rick_h | gary_poster: yes, we're waiting on a backend deploy to provide the data | 14:31 |
| Makyo | benji, I suppose I was under the impression that it had be deprioritized because the menu was going to be removed. I suppose I could pass off Francesco's branch to focus on this, though. | 14:31 |
| hatch | jujugui can I get some reviews https://codereview.appspot.com/10690046/ thanks :) | 14:31 |
| sinzui | gary_poster, we haven't deployed yet | 14:31 |
| bac | hatch: i'm about done with one | 14:31 |
| rick_h | gary_poster: since it's displayed/hidden and not error prone and we're asking for a deploy figured it was 'safe' for a short run | 14:31 |
| hatch | bac: ahh cool thanks, as you will notice I didn't really use much of what you had already :) sorry | 14:32 |
| rick_h | jcsackett: no, it's basically a refactor as is, so did LGTM it but was looking for the config side and took a sec to realize it wasn't there | 14:32 |
| bac | hatch: why is display.serviceName not rendering? | 14:32 |
| bac | on the settings page? | 14:32 |
| rick_h | adeuring: can you peek at https://code.launchpad.net/~rharding/charmworld/old-api-endpoints/+merge/172549 please? | 14:32 |
| adeuring | rick_h: sure | 14:32 |
| benji | Makyo: Gary made a criticial card for this and asked that you and I work on it, so prioritizing it seems appropriate | 14:33 |
| rick_h | adeuring: thanks, maybe I can get it in while sinzui's on calls and get it in before the deploy | 14:33 |
| Makyo | Buh. | 14:33 |
| Makyo | Okayl | 14:33 |
| hatch | bac: looking | 14:33 |
| Makyo | jujugui, Someone take Francesco's branch? | 14:33 |
| jcsackett | rick_h: ok. | 14:34 |
| jcsackett | sinzui: call? | 14:34 |
| hatch | bac: the model may not have a displayName property | 14:34 |
| sinzui | gary_poster, there wont be an interruption caused by the deploy because the fast-and-safe process is being used now. But with a robust server, we are allowing mediocre charms to be visible. There are a lot of charms that haven't ever been deployed (from the store). | 14:34 |
| sinzui | jcsackett, yes | 14:34 |
| hatch | rick_h: lemme know how those books are - if they are good I'll pick some up too :) | 14:34 |
| rick_h | hatch: will do | 14:34 |
| benji | Makyo: I don't think there is anyone else available. It'll probably be there for you when we get done. | 14:36 |
| adeuring | rick_h: r=me | 14:36 |
| rick_h | adeuring: thanks | 14:36 |
| Makyo | benji, Okay. So you're on #3 from the email, then? | 14:37 |
| benji | Makyo: nope, #2 | 14:38 |
| benji | although, I am able to dupe without drag and drop | 14:38 |
| Makyo | benji, I haven't been able to reproduce that one. Give me a sec to try some more. | 14:39 |
| benji | it looks a lot like a bug from a couple of months ago | 14:39 |
| Makyo | How so? | 14:40 |
| hatch | benji: I'm a little confused by your email - it sounds like you are reproducing number 3 not 2 | 14:41 |
| benji | hatch: my reading of 3 is that it requires a feature flag be enabled to reproduce; I am not enabling any feature flags | 14:41 |
| benji | hatch: it may be that I am describing a new bug | 14:42 |
| hatch | ok but #2 is that the relation line breaks after they are connected | 14:42 |
| hatch | so it sounds like you're talking about #3 | 14:42 |
| hatch | maybe we need a quick chat | 14:42 |
| benji | hatch: I see that as well as the end of the relation line being offset while tracking the mouse cursor position | 14:43 |
| hatch | yeah the offset is #3 and it's caused by the menu | 14:43 |
| gary_poster | apparently my laptop is going to fail randomly over the next few days | 14:44 |
| gary_poster | something to look forward to :-) | 14:44 |
| hatch | haha uh oh | 14:44 |
| hatch | blame the hardware right? | 14:44 |
| gary_poster | heh yeah, or the guy who installed the modifications to it (me) :-) | 14:44 |
| gary_poster | if anyone said anything to me after rick_h told me that we were waiting on a backend deploy to provide the data, I missed it, fwiw | 14:45 |
| benji | I told you nitrous oxide wouldn't be good for your laptop. | 14:45 |
| rick_h | gary_poster: just saying it'll be fixed later today :) | 14:45 |
| rick_h | so yes, known issue | 14:45 |
| gary_poster | :-) | 14:45 |
| gary_poster | cool thanks rick_h | 14:46 |
| rick_h | sinzui: the deprecated api endpoints branch is merged so when we do the deploy can we include that as well? | 14:46 |
| rick_h | benji: so heads up ^^ old api endpoints will soon 410 Gone to help debugging that stuff. | 14:46 |
| benji | thanks for the info, rick_h | 14:47 |
| Makyo | benji, can you test with lp:~makyo/juju-gui/rel-fix ? If that works, I'll explain what happened. If not, then it's probably not worth it :) | 14:52 |
| hatch | bac: maybe I missunderstood the purpose of this branch - I thought it was primarily a UI branch so I never hooked up the 'saving' of the new settings | 14:52 |
| Makyo | Wait, hold on benji | 14:52 |
| benji | heh | 14:52 |
| * benji holds. | 14:52 | |
| Makyo | benji, Sorry, forgot commit. It's ready now. | 14:53 |
| benji | k | 14:53 |
| bac | hatch: huh. if that's the case we need to make certain there is a card in place for hooking things up. the casual observer would assume that the fields were live. | 14:54 |
| hatch | the wireframe doesn't have a UI for 'save' so I wasn't really sure what to do haha | 14:54 |
| hatch | I suppose it could look like the one in the pre-deployment panel | 14:55 |
| gary_poster | arosales, sinzui are you all able to come to the design GUI meeting | 15:01 |
| arosales | gary_poster, on my way, wrapping up a meeting | 15:01 |
| benji | Makyo: your branch appears to fix both flavors of issue 2. I can't reproduce any relation line problems with it. | 15:02 |
| Makyo | benji, re: pending relations? I still have yet to reproduce the bug described in #2, with a completed relation. | 15:03 |
| jcsackett | jujugui: could i get a second review of https://codereview.appspot.com/10870043 | 15:05 |
| benji | Makyo: if by "pending" you mean "clicking on 'Build relation' and dragging one end of the relation around", yes. Also the "wait a little while and the relation line end no longer is in the right position" flavor of #2 | 15:05 |
| Makyo | benji, I just reproduced that right as you said it, heh. | 15:05 |
| hatch | jcsackett: on it | 15:05 |
| jcsackett | thanks, hatch. | 15:05 |
| Makyo | gary_poster, can we get some confirmation/clarification on which problem is #2 and which is #3? If this fixes one of them, I'd like to propose. If it's more complex than that, I'll switch. | 15:06 |
| benji | Makyo: you reproduced the second (lets call that one "unstuck relation lines")? Is that on your branch or an unfixed branch? | 15:07 |
| gary_poster | Makyo, sorry on call. happy wih landing incremental improvements | 15:07 |
| benji | Makyo: my reading of #3 is that reproducing it requires a feature flag be enabled. I have not enabled any while working on this. | 15:07 |
| Makyo | benji, yes. The only thing I fixed was in the mousemove event handler when creating a relation. | 15:07 |
| Makyo | benji, I suppose we can agree to disagree. Can we disambiguate differently to pending and created? | 15:08 |
| benji | Makyo: we can call them whatever we want. There are two fairly different bugs described in https://bugs.launchpad.net/juju-gui/+bug/1195934 which Gary called "2" in his email. | 15:09 |
| _mup_ | Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934> | 15:09 |
| benji | (note that I can reproduce the pending relation bug without drag and drop) | 15:09 |
| hatch | jcsackett: the branch is looking good - but should it not be configurable and set via the config.js files? | 15:12 |
| jcsackett | hatch: this is one step; subapp needs to support a variable default. the next step is the config flag. | 15:12 |
| jcsackett | this bit seemed like something i wanted eyes on earlier, and was landable without the second bit. | 15:12 |
| jcsackett | rick_h: got a sec to chat? | 15:13 |
| rick_h | jcsackett: sure | 15:13 |
| hatch | jcsackett: sure thing - review done | 15:14 |
| Makyo | benji, that' | 15:15 |
| Makyo | That's what I reproduced. | 15:15 |
| Makyo | The fix is for #3. No flags, because it's a problem with creating a relation from the service menu (which was removed with the flags we have) | 15:15 |
| benji | Makyo: define "that" | 15:15 |
| Makyo | benji, A created relation pointing to where a service used to be if you drag services around and let the simulator cycle a few times. | 15:16 |
| benji | I do not drag anything to reproduce the bug I am talking about. | 15:16 |
| Makyo | benji, That being the pending relation line showing up somewhere offset from the cursor when you move your mouse? | 15:18 |
| benji | Makyo: yep | 15:18 |
| benji | Gary's repro instructions are in this comment of the bug he labled "2": https://bugs.launchpad.net/juju-gui/+bug/1195934/comments/2 (but I don't have to do step 3 to repro) | 15:19 |
| _mup_ | Bug #1195934: Deploying service from dd & add causes positioning issues <juju-gui:New> <https://launchpad.net/bugs/1195934> | 15:19 |
| benji | (and I don't have to use drag-and-drop to deploy the services to see the problem) | 15:19 |
| Makyo | benji, My reading is that refers to a created relation line, rather than a pending one, since it's a verification of the attached image. I reproduced the behavior in the bug description, and my branch is for an unrelated problem (that of starting the relation build process from the service menu) | 15:21 |
| benji | Makyo: I agree with your reading too. The problem is, as best I can tell, is that there are actually two bugs being described there. | 15:22 |
| hatch | benji: Makyo I was the one who found these bugs so I can probably help you decide which is which :) | 15:23 |
| benji | Makyo: perhaps we should do some screen sharing so we can be explicit about what we are doing to reproduce each bug | 15:23 |
| hatch | sounds like a plan | 15:23 |
| Makyo | Sure. | 15:24 |
| Makyo | in guichat | 15:24 |
| hatch | jcsackett: PBDD lol | 15:38 |
| * jcsackett laughs | 15:38 | |
| Makyo | benji, hatch https://codereview.appspot.com/10873043 | 15:44 |
| hatch | on it | 15:44 |
| hatch | Makyo: there is only a single `svg g` right? | 15:45 |
| Makyo | hatch, yes. | 15:45 |
| Makyo | Same construct is used for pending relations created via the long-click method, which is why that works and this didn't. | 15:46 |
| hatch | ok - can you create a property to store that? it's making a DOM query every time the mouse moves now :) | 15:46 |
| hatch | I kind of wish YUI would cache those queries but I suppose I understand why it doesn't | 15:47 |
| Makyo | jujugui call in 6 kanban now | 15:54 |
| hatch | woops thanks Makyo | 15:54 |
| Makyo | hatch, done, reload rv | 15:55 |
| bac | Makyo: is that your card in maint? add your face? | 15:55 |
| Makyo | face: added | 15:55 |
| hatch | Makyo: thanks! lgtm'd | 15:57 |
| Makyo | jujugui call in 2 | 15:58 |
| * Makyo manages to make a coffee before then. Might as well attack migraine with everyone's favorite vasodilator. | 15:59 | |
| gary_poster | argh | 16:05 |
| bac | Makyo: you already have two reviews: benji and hatch | 16:06 |
| Makyo | Oh. Bonus. Thanks bac | 16:06 |
| bac | Makyo: i put my name on it but they beat me to it | 16:07 |
| hatch | https://codereview.appspot.com/10690046/ | 16:08 |
| bac | hatch: the problem with service.displayName is not really an issue as the wireframes just have 'Service settings'. so you should change to that static string. | 16:20 |
| hatch | ahh ok | 16:21 |
| hatch | I was just about to go through this new wireframe | 16:21 |
| hatch | looks like it has a cancel and confirm button for settings | 16:21 |
| hatch | so that answers that question | 16:21 |
| bac | yeah, old and new both have that | 16:21 |
| bac | ('Service settings' i mean) | 16:22 |
| hatch | gary_poster: this dropbox example is still a WIP? | 16:25 |
| gary_poster | hatch, yes | 16:25 |
| hatch | ok 'll hold off then as I'm sure my comments are just things he hasn't gotten to yet :) | 16:26 |
| gary_poster | :-) cool | 16:26 |
| hatch | hehe firefox only - who would have thought | 16:26 |
| hatch | ;) | 16:26 |
| hatch | benji: thanks for the review | 16:49 |
| benji | my pleasure | 16:49 |
| Makyo | benji, hatch https://codereview.appspot.com/10876044 | 17:17 |
| hatch | Makyo: on it | 17:17 |
| hatch | Makyo: this is great that these fixes were so trivial - I am wondering if these things should be documented somewhere - like an idiots guide to our d3 system :) | 17:18 |
| Makyo | hatch, that's one of my goals. | 17:18 |
| hatch | eggcelent :) | 17:22 |
| sinzui | Yesterday "pending" meant local juju deploys is broken. Today "pending" means local juju deploys might work. | 17:31 |
| hatch | Schrödinger's Pending ? | 17:32 |
| hatch | you never know what pending means until you observe it :) | 17:33 |
| sinzui | hatch exactly. Pending public address might mean juju doesn't have cloud-templates to build the lxc. pending status means the contain built, and I am waiting the the charm to tell me don't attempt to call a script you haven't unpacked yet. | 17:37 |
| hatch | this sounds like a future bug request in the making ;) | 17:37 |
| sinzui | I think the problem is ultimately between th seat and the keyboard. | 17:38 |
| hatch | "error: pebkac" | 17:40 |
| sinzui | Though, maybe juju should admit it depends on cloud-utils to deploy to lxc | 17:40 |
| sinzui | hmm, I cannot see how cloud-utils got uninstalled since lxc-templates requires it. | 17:42 |
| hatch | bcsaller: can we remove the 'simulator started' console logs? :-) | 17:43 |
| bcsaller | fine by me | 17:44 |
| hatch | fyi all - the font mime type warnings will be going away in chrome soon...YAY! | 17:44 |
| rick_h | can i get some reviews on this please? Since it's a -req branch from Huw's work which has not been reviewed I couldn't get reitveld to do the diff cleanly. https://code.launchpad.net/~rharding/juju-gui/new-controls/+merge/172631 | 17:44 |
| bcsaller | hatch: that was there when it defaulted to off and had a hot key trigger for dev work, but its not needed now | 17:44 |
| rick_h | hatch: jcsackett sinzui Makyo ^^ | 17:44 |
| rick_h | it won't be anything that lands until huw's work completes and he'd pull this into his work to land | 17:44 |
| * sinzui looks | 17:45 | |
| hatch | bcsaller: ahh ok - I just notice it spams the test logs, will remove :) | 17:45 |
| rick_h | hatch: yea, saw that. Very cool | 17:45 |
| rick_h | hatch: one day, we might get an empty console on load! :P | 17:45 |
| hatch | lol keep dreaming | 17:45 |
| hatch | rick_h: reviewing | 17:45 |
| rick_h | hatch: oh come on! | 17:45 |
| hatch | haha | 17:46 |
| rick_h | hatch: thanks for the peek at the review bit. | 17:46 |
| hatch | yesterday it was 30c and 50% humidity - was pretty sure I was going to melt | 17:48 |
| rick_h | hatch: yea, it's finally cooled off here the last couple of days. | 17:48 |
| hatch | it's so hot the wind refuses to blow | 17:49 |
| hatch | rick_h: so how am I supposed to comment? just ping you in here? | 17:50 |
| rick_h | hatch: yea, or you can leave comments in the MP there. | 17:50 |
| hatch | index.html:15 spacing issue | 17:50 |
| rick_h | hatch: I've got a reitveld review up but it sucked ina bunch of extra stuff. | 17:50 |
| rick_h | https://codereview.appspot.com/10877043 | 17:50 |
| hatch | i'd say haha | 17:50 |
| sinzui | rick_h, does this branch have revisions other than trunk | 17:51 |
| rick_h | hatch: but I'd like to get my bit 'ok'd' and huw can pull it into his work safely | 17:51 |
| rick_h | sinzui: yes, it's dependent on huw's branch in the MP | 17:51 |
| sinzui | yeah, I see "download" changes and drag-drop changes | 17:51 |
| rick_h | https://code.launchpad.net/~huwshimi/juju-gui/visual-update-1 | 17:51 |
| hatch | bac: could you take another look at my branch and LGTM if you like | 17:51 |
| rick_h | sinzui: yea, MP kept the new trunk updates out of the way, but reitveld wants to bring things from trunk that have changed as well | 17:52 |
| bac | hatch: ok | 17:52 |
| rick_h | sinzui: why I tried to stick to the LP MP first | 17:52 |
| sinzui | rick_h, I think you can tell lbox your branch depends on another to limit the changes shown | 17:52 |
| rick_h | sinzui: I did, this is with the -req="" flag used | 17:52 |
| sinzui | rick_h, its okay. I know how to get a diff of just your changes. | 17:52 |
| rick_h | lbox propose -cr -v -edit=true -req="lp:~huwshimi/juju-gui/visual-update-1" (command used) | 17:53 |
| sinzui | ah, Lp is correct | 17:53 |
| gary_poster | hatch, bcsaller, benji, Makyo hi. please head over to allhands and do the counter-sign sometime in the next hour or so | 17:53 |
| * hatch has no idea what you're talking about but looking ;) | 17:55 | |
| hatch | countersigned! | 17:55 |
| hatch | unless I screwed something up again :P | 17:55 |
| rick_h | hatch: quit breaking things! | 17:56 |
| hatch | ""The objective sheet can't be anymore updated"" lol | 17:56 |
| hatch | rick_h: oh I got this down! | 17:57 |
| hatch | I don't think I'll be able to break it again until next year | 17:57 |
| hatch | rick_h: your widget events should be documented with @event and IMHO the controls should be a view instead of a widget | 17:58 |
| Makyo | gary_poster, done. | 17:59 |
| rick_h | hatch: so they don't share a common parent to be a view and it's splitting an existing widget so kept the things working. Plus the widget doesn't 'render' output like the view would | 17:59 |
| gary_poster | cool thanks guys. hopefully it will show up in my list of tasks soon. | 17:59 |
| gary_poster | but anyway your side is done | 17:59 |
| rick_h | hatch: so disagree? :) I could make it a pure JS class vs a widget, but again just trying to split work on existing code. | 18:00 |
| sinzui | rick_h, I seethis.publish(this.EVT_TOGGLE_FULLSCREEN); | 18:01 |
| sinzui | but you removed the definition of EVT_TOGGLE_FULLSCREEN | 18:01 |
| rick_h | hatch: as for the @event, you're right. /me goes to look at someone doing that right to copy | 18:01 |
| Makyo | jujugui, Can I get another look at https://codereview.appspot.com/10876044/ ? Last critical. | 18:01 |
| * sinzui thinks it is undefined | 18:01 | |
| rick_h | sinzui: thanks, yea that sohuld be the two new events fullscreen/sidebar | 18:01 |
| hatch | rick_h: reviewing to see if I can be convinced (re widget) | 18:02 |
| Makyo | Oops, second to last, sorry. | 18:02 |
| benji | Makyo: I'll review it if you still need one (I was lunching) | 18:02 |
| rick_h | hatch: yea, I can be convinced to drop Y.Widget I suppose, but not to a Y.View. | 18:02 |
| Makyo | benji, Sure, that'd be good. Thanks. | 18:02 |
| hatch | rick_h: so the idea is that this progressively enhances an element already on the page to add these events and the like? | 18:03 |
| rick_h | hatch: rgr | 18:04 |
| rick_h | hatch: the navigation header has already been rendered in index.html and this binds browser events to it | 18:04 |
| rick_h | sinzui: pushing that fix now, hatch fix also includes @event docs in the new widget. | 18:06 |
| * sinzui looks again | 18:06 | |
| hatch | cool - ok so will agree that a view probably isn't the right way, but a widget is way to heavy | 18:07 |
| hatch | could this go in an app.js extension? | 18:07 |
| hatch | er | 18:07 |
| hatch | browser app extension | 18:07 |
| rick_h | hatch: no, it needs ot be in the browser subapp to go through it's viewState code. | 18:07 |
| rick_h | ah, hmm...well maybe kinda. It puts some UX responsibility up to the app level like that. Maybe a View extension... | 18:08 |
| hatch | do you agree that a widget for this is too heavy? | 18:08 |
| benji | gary_poster: countersigned | 18:08 |
| rick_h | hatch: yes, I agree that it's heavier than needed, but trying to split work vs ditch widgets. | 18:08 |
| rick_h | hatch: and it's a single instance, each view destorys/recreates as you toggle so not a lot of overhead. | 18:09 |
| gary_poster | thanks benji | 18:09 |
| hatch | brb 2min will think about it | 18:09 |
| bac | hatch: done | 18:09 |
| hatch | bac: thanks | 18:12 |
| gary_poster | rick_h, is the charm store something that runs per environment, or is it something that runs in a known location, like m.j.c? I don't understand what the charm store is, or how m.j.c uses it. I only understand that it is the way that Juju finds charms. Can you explain or give me a pointer to an explanation? | 18:13 |
| rick_h | gary_poster: heh, I've always been a bit fuzzy myself. sec, let me get the url. | 18:14 |
| gary_poster | thans | 18:14 |
| gary_poster | k | 18:14 |
| sinzui | gary_poster, the charm store is a website without pages | 18:14 |
| gary_poster | sinzui, ah ok thanks | 18:14 |
| gary_poster | rest API sinzui ? | 18:14 |
| sinzui | gary_poster, yep rest and json. The charm browser aggregates data from it Lp, jenkins, and a local run of proof | 18:15 |
| rick_h | gary_poster: so the only instance I know of for it is https://store.juju.ubuntu.com and we get stats like downloads from it via api calls like https://store.juju.ubuntu.com/stats/counter/charm-bundle:precise:apache2 | 18:15 |
| gary_poster | sinzui, so m.j.c essentially just provides indexing of the data in the charm store? | 18:16 |
| hatch | rick_h: I'm probing for some input in #yui as I think that the binding could be moved into a bindUI method in the subapp | 18:16 |
| rick_h | hatch: no, at least the toggle can't be moved there. | 18:17 |
| rick_h | hmm, well maybe it *could* I guess. I use a delegate stuff now | 18:17 |
| sinzui | gary_poster, that plus normalisation to ensure the charm can be accessed | 18:17 |
| hatch | sure and you could still do that | 18:17 |
| hatch | there is nothing saying you couldn't do that Y.one('#content') in a bind method | 18:18 |
| rick_h | hatch: yea, just that right now the app has no idea about HTML structure/etc. It's all in views and they are easy to test that way. | 18:18 |
| gary_poster | sinzui, rick_h, ok, thank you very much. | 18:18 |
| rick_h | it feels really really ditry to me | 18:18 |
| hatch | right | 18:18 |
| hatch | see in a past project we had a view which managed the navigation | 18:18 |
| sinzui | gary_poster, These charms for example cannot be deployed, and until last week, we could not even show in the browser until we sanitised them: http://manage.jujucharms.com/tools/store-missing | 18:18 |
| hatch | but we have all but avoided that | 18:18 |
| rick_h | hatch: like I said, if I *had* to I'd move it up to the subapps/views/view.js that they all share. It's handlig the widget currently. | 18:19 |
| gary_poster | ah, I see what you mean sinzui | 18:19 |
| hatch | rick_h: ok....yeah that looks good - can you do that? :-) | 18:19 |
| rick_h | hatch: I guess I'm saing I agree that it's heavy-weight, but for a quick refactor to help aid Huw in UX redesign that's more work in a new path than this is meant for. | 18:20 |
| hatch | ohh ok | 18:20 |
| rick_h | hatch: yea, I could. | 18:20 |
| hatch | rick_h: oh sorry, I never sent | 18:32 |
| hatch | LGTM for now....... :P | 18:32 |
| gary_poster | benji, Makyo looks like you are making progress. have you fixed 2 or 3 of the 4? | 19:15 |
| gary_poster | I mean, which one. :-) | 19:15 |
| gary_poster | 2, or 3 | 19:15 |
| Makyo | gary_poster, both relation branches have landed. | 19:15 |
| Makyo | Oops, will update board. | 19:16 |
| gary_poster | Makyo, fantastic. so the only thing left is the configuration issue, benji? | 19:16 |
| benji | gary_poster: 1 (yesterday), and 2b and 3 have landed (I'm pretty sure), and right, my issue is the last which I believe I'll have done in the next 30 minutes or so | 19:16 |
| Makyo | All instances of 2 and 3 have landed as of two minutes ago or so. | 19:17 |
| gary_poster | benji, Makyo, great! thanks. computer would stop crashing, things would be great. :-) | 19:18 |
| benji | a computer never crashes if it's off | 19:19 |
| gary_poster | :-) | 19:19 |
| sinzui | jcsackett, do you have a few minutes to hangout to discuss why failed to to get my dequeue branch into review? | 19:28 |
| jcsackett | sinzui: give me 10 minutes? | 19:29 |
| sinzui | thank you | 19:29 |
| jcsackett | sinzui: Ok, sending invite now | 19:45 |
| jcsackett | ...or not. | 19:46 |
| sinzui | jcsackett, Is the landlord kicking you out every time you invite people to your party? | 19:51 |
| jcsackett | sinzui: It kept telling me you aren't around. | 19:51 |
| jcsackett | Shall I call again? | 19:51 |
| sinzui | yes | 19:51 |
| hatch | bcsaller: the 'please take a look' email didn't include a link :) | 20:16 |
| bcsaller | hatch: https://codereview.appspot.com/10760046/ and corrected on the card | 20:16 |
| hatch | cool thx | 20:16 |
| hatch | that was odd it was missing the link | 20:16 |
| bcsaller | propose didn't pick up the -cr flag for some reason | 20:17 |
| hatch | ahh | 20:17 |
| gary_poster | sinzui, am I right that there is no way to get information about an earlier revision of a charm from m.j.c, but we can get pretty much everything from store.juju.ubuntu.com? If we knew a precise revision, would their be a clear path to getting that information from the store? Relatedly, how do you find out the API of store.juju.ubuntu.com? | 20:18 |
| sinzui | gary_poster, I don't think there is a clear way to get info about a revision. We discussed pulling each zip from the store, unpacking them, then scanning them for data | 20:20 |
| gary_poster | ah | 20:20 |
| gary_poster | wow | 20:20 |
| gary_poster | I found https://juju-docs.readthedocs.org/en/latest/internals/charm-store.html | 20:21 |
| gary_poster | reviewing a bit | 20:21 |
| gary_poster | sinzui, is that how you handle a charm head as well--m.j.c scans them too? Or does the store give more for the charm head than it appears to? | 20:27 |
| sinzui | We only use the store to get the download counts and a report about the store's sense of quality | 20:28 |
| gary_poster | ah ok | 20:28 |
| sinzui | We use the Lp branch for history, files, and proof | 20:28 |
| gary_poster | oh | 20:29 |
| gary_poster | so...could you do the same for old versions? or that's not reliable/efficient, because bzr version does not equal charm version? ? | 20:30 |
| benji | jujugui: critical bug fix up for review: https://codereview.appspot.com/10887043 | 20:32 |
| hatch | on it | 20:32 |
| bac | benji: me too | 20:33 |
| benji | thanks guys | 20:33 |
| bac | benji: done | 20:36 |
| benji | bac: thanks! | 20:36 |
| sinzui | gary_poster, these are the two URLs the cb users to talk to the store: | 20:37 |
| sinzui | https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui | 20:37 |
| sinzui | ^ get the current version of the charm | 20:37 |
| sinzui | ^ which tells us the version number | 20:37 |
| benji | bac: I had to google OAO, it was a close call between "over and out" and "Opticians Association of Ohio" | 20:37 |
| sinzui | gary_poster, https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui-61 | 20:37 |
| bac | i've never been to ohio | 20:37 |
| sinzui | gary_poster, ^ is a variant to to see an older version | 20:38 |
| bac | in my rich fantasy life i am a helicopter pilot, however | 20:38 |
| sinzui | gary_poster, this is the url to get the download counts for a charm: https://store.juju.ubuntu.com/stats/counter/charm-bundle:precise:juju-gui?format=json | 20:38 |
| hatch | benji: this doesn't look like it effects the new inspector - did you QA the new inspector with this branch? | 20:38 |
| benji | hatch: I don't think it will effect the new inspector - no I didn't | 20:39 |
| hatch | mind doing that so I don't have to make it? :) | 20:39 |
| hatch | make just takes so long on this thing hah | 20:39 |
| gary_poster | bac, lol | 20:39 |
| gary_poster | x 2 | 20:39 |
| * Makyo -> vet. | 20:40 | |
| hatch | bcsaller: review done | 20:40 |
| gary_poster | sinzui, ah ok. so really everything is in place to get the historical information in about the same way you are currently getting the trunk info, IIUC | 20:40 |
| bcsaller | hatch: thanks, following up | 20:40 |
| sinzui | yes | 20:40 |
| sinzui | gary_poster, 1. record the version we have now and mark the current one so that it is indexed for search. | 20:41 |
| benji | bac: lol | 20:41 |
| sinzui | gary_poster, 2. add a proc to get the history of the old revs, then queue them for ingestion so that they can be directly looked up | 20:42 |
| benji | hatch: how do I enable the new inspector? | 20:42 |
| hatch | /:flags:/serviceInspector/ | 20:42 |
| * gary_poster just did that without the preceding space :-P | 20:42 | |
| hatch | which coincidently freenode does not understand /:flags:/ | 20:43 |
| hatch | gary_poster: lol same haha | 20:43 |
| gary_poster | :-) | 20:43 |
| hatch | coincidentally even | 20:43 |
| benji | hatch: it appears to work, in that the fields are visible, but the panel itself is all kinds of jacked up... it that normal? (i.e., it is too big to fit on the screen, the colors are such that it is just about illegible, if I click on an existing service to show the inspector and then click on a charm in the browser to deploy it the inspector stays above the browser) | 20:46 |
| hatch | yup that's all known | 20:46 |
| hatch | ok thanks for checking that | 20:46 |
| hatch | :) | 20:46 |
| benji | cool | 20:46 |
| hatch | lgtm'd | 20:47 |
| * benji lands. | 20:49 | |
| hatch | gary_poster: after benji 's fix lands I believe that's all 3 so I can start the QA again - do we still want to release? | 20:55 |
| gary_poster | hatch, all 4 even. we do very much want the release, thank you. | 20:55 |
| hatch | yeah....4 :) | 20:55 |
| benji | hatch: branch landed | 20:55 |
| hatch | benji: thanks, rockin the QA now | 20:56 |
| hatch | gary_poster: when I make a relation using the service-menu it's connection point on the 'starting' service is off center and pops back to place when you move the service, it's proper when using the long click. This is hardly a breaking issue just thought I'd point it out | 21:06 |
| gary_poster | hatch, ok. I'm ok with releasing with that, though if Makyo has a quick fix that's cool too. | 21:06 |
| hatch | :///// | 21:12 |
| gary_poster | hatch, ? | 21:13 |
| hatch | well there is some wakoness that I can't reproduce | 21:14 |
| hatch | so trying to reproduce to see if it's a one time thing or if it's a real issue | 21:14 |
| hatch | when you drag & drop the icons are left in the dom behind the environment | 21:14 |
| hatch | ^ we should have a ticket for that | 21:14 |
| hatch | I'll make | 21:15 |
| hatch | the height calculation for the view-container that the (old) service inspectors get rendered into is too high by 18px | 21:18 |
| hatch | (should fix before release) | 21:18 |
| hatch | gary_poster: when switching between views it shows the brown background for a second (sometimes) which exposes the icons left in the DOM (https://bugs.launchpad.net/juju-gui/+bug/1197152) not sure how much of an issue this is... | 21:19 |
| _mup_ | Bug #1197152: Drag & drop icons are left in the DOM after dropping <juju-gui:New> <https://launchpad.net/bugs/1197152> | 21:19 |
| hatch | actually forget that, they aren't just in the dom, they are appended to the end of the dom | 21:20 |
| hatch | benji: still around? | 21:20 |
| benji | hatch: yep; I've been half-following along | 21:21 |
| hatch | guichat real quick so I can show you? | 21:22 |
| hatch | this drag and drop just won't die haha | 21:22 |
| gary_poster | hatch that sounds like a trivial fix? | 21:23 |
| benji | hatch: I'm sure I know what is happening. | 21:23 |
| hatch | benji: ok cool, as long as you can repro | 21:23 |
| hatch | I was just going to step through the repro steps | 21:24 |
| benji | If they are in the bug, that will be best. | 21:24 |
| hatch | ok I'll detail it out a bit | 21:26 |
| hatch | benji: updated with full repro steps | 21:27 |
| benji | great | 21:30 |
| hatch | the charm page has lost it's scrollbar someways along the way | 21:31 |
| hatch | looks like a side effect of some responsive word | 21:31 |
| hatch | work* | 21:31 |
| hatch | benji: if you wouldn't mind including this fix for the height calculation issue https://gist.github.com/hatched/b68e07f1832c1c085ceb | 21:33 |
| hatch | 1 char diff....awww yeah | 21:33 |
| hatch | ;) | 21:33 |
| benji | hatch: sure | 21:36 |
| hatch | thank yas | 21:36 |
| hatch | now the question is....why wont' this charm page scroll :/ | 21:37 |
| hatch | oh odd - it works fine on devel but not on prod | 21:57 |
| hatch | ok must have been a cache issue | 22:00 |
| hatch | benji: any luck with that DD issue? | 22:10 |
| gary_poster | heh, guessing not | 22:14 |
| gary_poster | bcsaller, https://codereview.appspot.com/10760046/ LGTM with trivia; | 22:14 |
| gary_poster | l | 22:14 |
| hatch | hah ok - I guess release will be pushed till tomorrow :) | 22:14 |
| hatch | there are some odd issues wrt delta updates while dragging | 22:14 |
| hatch | but I'm certain that's the 20 of the 80/20 rule especially for a pre 1.0 | 22:15 |
| gary_poster | hatch, did he tell you he was working on it? From the sound of it would be easy to fix | 22:15 |
| hatch | I guess I just assumed | 22:15 |
| gary_poster | hatch, delta updates with dragging: curious, but maybe file a bug? | 22:15 |
| hatch | yeah as soon as I can create a repro heh | 22:15 |
| gary_poster | heh | 22:15 |
| hatch | I'll dig into the dd stuff | 22:15 |
| hatch | maybe it is trivial | 22:15 |
| * gary_poster wanted my nice shiny release | 22:15 | |
| gary_poster | thank you | 22:15 |
| gary_poster | ! | 22:15 |
| hatch | lol | 22:16 |
| hatch | ""LOL, that's deep, man. :-)"" | 22:16 |
| bcsaller | it should only update annotations on a dragend event, that sounds off | 22:21 |
| hatch | I have 'fixed' the drag icon issue but I don't like it | 22:35 |
| hatch | bcsaller: are you aware of any way to get the dragged item from the d3 drop event? | 22:35 |
| hatch | I can only see the svg stuff in the event | 22:35 |
| bcsaller | hatch: I can look | 22:36 |
| hatch | well I don't want to waste your time | 22:36 |
| hatch | I Just find it odd that the DOM event doesn't include reference to the dragged element | 22:37 |
| hatch | well the event is actually being caught as 'mousemove' | 22:37 |
| bcsaller | hatch: it looks like all that code, is in topology/service.js and the dragend handler should be doing it. That gets both the box (the visual model) and the datamodel under it is its handler so you can see how its done | 22:37 |
| hatch | maybe I can put the reference in the charmData that it sends | 22:38 |
| hatch | now I'm just talking to myself | 22:39 |
| hatch | sorry hah | 22:39 |
| bcsaller | oh, this is the charm token thingie, haven't looked at how that is done | 22:39 |
| bcsaller | happy to chat about it soon | 22:39 |
| bcsaller | hatch: let me know if you need to talk about it | 22:44 |
| hatch | bcsaller: nope, this way is a lot nicer thanks | 22:45 |
| hatch | just needed some sound boarding :) | 22:45 |
| gary_poster | biab | 22:52 |
| hatch | I'm so confused about bzr shelve | 22:58 |
| hatch | Changes shelved with id "1". | 22:59 |
| hatch | bzr: ERROR: No changes are shelved with id "1". | 22:59 |
| hatch | good thing I did a good ol diff dump before that | 23:00 |
| huwshimi | Morning | 23:03 |
| hatch | morning huwshimi how are things? | 23:03 |
| huwshimi | hatch: Good thanks, yourself? | 23:03 |
| hatch | good good just taking another stab at releasing hah | 23:06 |
| huwshimi | Fun! | 23:08 |
| hatch | yeah I am pretty sure I just squashed the last but | 23:08 |
| hatch | bug | 23:08 |
| hatch | even | 23:08 |
| hatch | arg | 23:11 |
| hatch | there is definitely something messed up when you drag and a delta comes in | 23:27 |
| hatch | Makyo: happen to be around still? | 23:30 |
| Makyo | hatch, barely. | 23:30 |
| hatch | deltas coming in while dragging jumps the service away from your cursor to last known position - known issue? | 23:31 |
| Makyo | I believe so, yeah. Let me hunt. | 23:31 |
| Makyo | For brevity's sake, is this on improv or simulator? | 23:32 |
| hatch | both - happens on simulator faster though | 23:32 |
| hatch | for obvious reasons | 23:32 |
| Makyo | 1 sec | 23:33 |
| hatch | jujugui looking for reviews for critical bug fix https://codereview.appspot.com/10872044/ | 23:36 |
| Makyo | hatch, was existing, but there's a 1 line fix if you want to put it in that same branch. | 23:39 |
| hatch | ok can do | 23:40 |
| hatch | diff me! | 23:40 |
| Makyo | http://pastebin.ubuntu.com/5838912/ | 23:40 |
| hatch | cool thanks I'll add that in | 23:40 |
| Makyo | Will review, too. | 23:40 |
| hatch | thanks | 23:43 |
| hatch | hmm wth | 23:44 |
| hatch | I don't think annotations are sent on drag end when using dd | 23:44 |
| rick_h | hatch: comments inbound. | 23:46 |
| rick_h | hatch: couple of questions due to quick run through. | 23:46 |
| hatch | thanks rick_h Makyo | 23:47 |
| rick_h | huwshimi: you get my email? Everything cool then? | 23:51 |
| hatch | ok the annotations are being updated | 23:53 |
| hatch | but it doesn't appear to be effecting the relation line | 23:53 |
| rick_h | of course not :P | 23:54 |
| hatch | bah I gota go eat supper, might try and get back to this tonight | 23:54 |
| huwshimi | rick_h: Yep, that's great. Thanks very much. I haven't pulled it yet, but will let you know if I hit any issues. | 23:55 |
| huwshimi | (I agree with not doing the minimised search for now too) | 23:55 |
| rick_h | huwshimi: ok cool. Let me know how it goes | 23:59 |
| huwshimi | rick_h: Cheers, thanks for getting to it so quickly. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!