| * frankban lunches | 11:02 | |
| rick_h_ | morning | 11:34 |
|---|---|---|
| frankban | hi rick_h_ | 11:54 |
| rick_h_ | how goes the battle frankban | 11:55 |
| frankban | rick_h_: I just proposed another inc step for utils. juju-core migration scheduled for Thu: at this point I'd wait before migrating packages, we still need to fix internal stuff in core. also tracking progress on the more important battle (EU elections) ;-) | 11:58 |
| rick_h_ | frankban: hah, sounds like a plan to me | 11:59 |
| rick_h_ | frankban: will be interesting to see how this move goes | 11:59 |
| frankban | rick_h_: +1 | 12:03 |
| hatch | good morning those who didn't take today as a holiday :) | 13:54 |
| hatch | anyone up for a big review? https://github.com/juju/juju-gui/pull/342 | 13:54 |
| rick_h_ | hatch: give me 10 to get the boy settled and I'll break into it | 14:18 |
| rick_h_ | hatch: code feedback posted, will qa after standup | 14:50 |
| rick_h_ | jujugui call in 10 kanban please | 14:50 |
| hatch | ok looking | 14:50 |
| Makyo | jujugui call in 2 | 14:58 |
| hatch | rick_h_ comments replied to | 15:14 |
| rick_h_ | hatch: cool catching up | 15:15 |
| hatch | Makyo working on your qa | 15:16 |
| hatch | abentley in your email when you said git doesn't have a revno, I'm assuming the partial hash for some reason doesn't work? | 15:22 |
| hatch | Makyo do you have a follow-up card or bug for the re-requesting icons that was introduced here? | 15:22 |
| rick_h_ | hatch: it's just a different place to get the data. We had to make the same adjustment | 15:22 |
| abentley | It's not an integer where a higher number is more recent. I'm not saying that *is* a problem, but at this stage, I don't know. We often do use that property of revnos. | 15:22 |
| hatch | ohh gotcha | 15:23 |
| hatch | there might be a way to query the git db to find out the order of the hashs | 15:24 |
| hatch | if that was really a requirement | 15:24 |
| Makyo | hatch, I'm seeing that in trunk, too, FWIW, but sure, I'll make one. | 15:25 |
| rick_h_ | Makyo: please stick it in maint on deck | 15:25 |
| hatch | Makyo really? I was sure it wasn't happening last week on comingsoon | 15:25 |
| hatch | lemme check again just to be sure | 15:25 |
| Makyo | It's happening locally. | 15:25 |
| abentley | hatch: Yes, though we might just change what the script does instead. | 15:26 |
| rick_h_ | hatch: ok, replied to your replies, let me know if it'll help to chat | 15:27 |
| hatch | Makyo interesting, I can't get it to happen on comingsoon - I wonder if it's a server difference | 15:29 |
| hatch | charm vs not | 15:29 |
| frankban | fwereade: I am working on a branch for preventing utils to use BaseSuite where possible. My understanding is that BaseSuite is very juju-core related, and often not required for stuff like utils. How does it sound? | 15:30 |
| hatch | rick_h_ ok looking | 15:30 |
| Makyo | I'm of the opinion that this is very low priority, given a) we're returning a 304, so cached assets are used, and b) it only happens in simulator envs when relation-changed hooks fail. The root of the problem is that we're changing the xlink:href attribute on svg <image> tags, so the solution is to load every icon for every relation and show/hide them with CSS, which seems like an optimization we don't need to worry about. | 15:30 |
| Makyo | i.e.: it's on the browser, and the browser's doing the right thing with the 304s. | 15:31 |
| hatch | so the original issue was that on every delta the icon would flash as it reloaded - that doesn't appear to happen any longer | 15:35 |
| hatch | so you're probably right that it's very low | 15:35 |
| hatch | regardless I +1'd your branch with a trivial :) | 15:36 |
| Makyo | Yeah, previously we removed the icon, then added a <image> back in, now we just change the href. | 15:37 |
| hatch | rick_h_ Here is a response to your concerns lemme know if you'd like to chat after this https://github.com/juju/juju-gui/pull/342#discussion_r13050921 | 15:40 |
| rick_h_ | hatch: yea, standup hangout? | 15:41 |
| hatch | sure, sec | 15:41 |
| rick_h_ | Makyo: lint fun in landing | 16:00 |
| Makyo | D'oh. On it/. | 16:01 |
| fwereade | frankban, we would hope to have a common BaseSuite that stripped out the core-specific bits, more than we would hope to lose it entriely | 16:07 |
| frankban | fwereade: some of the tests in utils do not require embedding other suites, others really only require CleanupSuite | 16:09 |
| * hatch proposes typescript | 16:09 | |
| hatch | after using Go it would sure be nice to catch some of these type errors before refreshing :) | 16:10 |
| rick_h_ | hah | 16:10 |
| hatch | rick_h_ can you link me to that loc where you reset the filter again? I just want to compare against what I'm attempting | 16:12 |
| hatch | the filter is definitely not being reset on 'home' | 16:12 |
| rick_h_ | hatch: sure thing sec, have to load it up again | 16:12 |
| hatch | this must have been a long standing bug we never ran into for some reason | 16:12 |
| rick_h_ | https://github.com/juju/juju-gui/pull/326/files 204 | 16:13 |
| hatch | rick_h_ if you click the number it will give you a link directly to that loc even in diffs | 16:13 |
| rick_h_ | hatch: doh | 16:13 |
| rick_h_ | hatch: yea, having a major monday today. You won't believe how it's gone | 16:13 |
| rick_h_ | hatch: so yea, there. I | 16:13 |
| hatch | haha thanks | 16:13 |
| rick_h_ | hatch: so this isn't so much a bug as when the new state was setup we had no filter, when we added back filter we didn't update the Home event to fire the new way it needed to | 16:14 |
| rick_h_ | hatch: but we had this card to work on that | 16:14 |
| rick_h_ | hatch: which is what this card originally start out as | 16:14 |
| hatch | so...this feels like the wrong way to do this....should the state not be smart enough to see that there is no search and upate the filter accordingly? | 16:14 |
| rick_h_ | hatch: well, "Home" is like a giant erset | 16:14 |
| rick_h_ | reset | 16:14 |
| frankban | fwereade: the change is in https://codereview.appspot.com/101760045 | 16:14 |
| rick_h_ | hatch: and it has to communicate through a 'change' event so it has to be structured somehow in there? | 16:15 |
| rick_h_ | hatch: sec, phone call. back in a sec | 16:15 |
| hatch | I'm just wondering if it makes sense to move this search.clear = true bit into the state parsing | 16:15 |
| hatch | sure np | 16:15 |
| hatch | so if metadata.search === undefined || null then wipe the filter | 16:15 |
| hatch | it requires less discovery for the developer then if they ever want to clear the search, they just null it out in the state object | 16:16 |
| fwereade | frankban, cheers | 16:20 |
| rick_h_ | hatch: yea, I felt like there was some reason. I think it's because you have to change more than just the search term, you have to clear the category stuff and anything else in that filter object over time | 16:23 |
| rick_h_ | hatch: so the clear() was a way to tell the filter object to just reset entirely | 16:23 |
| hatch | right - but now that we have this fancy state object can we not safely say that if metadata.search is undefined or null then filter should be cleared and drop the requirement for metadata.search.clear ? | 16:24 |
| hatch | another way to say it is, when would we not want to clear filter if metadata.search is undefined or null | 16:25 |
| rick_h_ | hatch: because the way a search via the api works is you can have a category without a search term | 16:25 |
| rick_h_ | hatch: when the user picks the autocomplete drop down for 'databases' it doesn't send a term that I recall | 16:26 |
| hatch | so the category isn't entered into the metadat.search object? | 16:26 |
| hatch | your right, term is empty | 16:26 |
| rick_h_ | hatch: so I think keying off the one field is dangerous and limiting scope too much | 16:26 |
| hatch | ok lemme check the state object when I search a category | 16:26 |
| rick_h_ | ok | 16:27 |
| hatch | rick_h_ ok good news - the filter data is present in the metadata.search object so we can safely check that if it's null, undefined, or an empty object to clear the filter | 16:31 |
| rick_h_ | hatch: ok, and if you make a change, like clicking on a charm in the results to get the details open, it won't be effected by not having a search key? | 16:32 |
| hatch | it looks like it mixes properly...checking the execution | 16:34 |
| rick_h_ | hatch: ok cool, just want to make sure that we don't accidently break other cases | 16:34 |
| hatch | the search object is correcly left untouched | 16:34 |
| rick_h_ | cool | 16:34 |
| hatch | nice | 16:34 |
| rick_h_ | so that's cool then, I think it'll simplify things and make them more direct/explicit | 16:35 |
| rick_h_ | thanks for chasing that down | 16:35 |
| hatch | agreed | 16:35 |
| hatch | np | 16:35 |
| hatch | lazyPower marcoceppi is there a website somewhere which shows the status of charm reviews so I can see where my ghost charm is in the queue? | 16:43 |
| hatch | rick_h_ this is hard to grep for....do you remember when you'd want to do filter replace vs filter update? | 16:51 |
| rick_h_ | hatch: thinking | 16:51 |
| hatch | as far as I can see the search widget always uses replace true | 16:51 |
| rick_h_ | hatch: I think the idea was around categories. If you picked a new category, we'd clear out the search term, filters, etc, and just create a new filter with only the category selected | 16:52 |
| rick_h_ | hatch: yea, I think that harkens back to the filter/series/etc UI | 16:52 |
| hatch | could this be the bug which causes new search queries to always use the old category? | 16:52 |
| rick_h_ | hatch: it's part of it. The old system was checkboxes that built on each other | 16:53 |
| hatch | ahh | 16:53 |
| rick_h_ | you'd check "category X" and then click "series Y" | 16:53 |
| rick_h_ | and it would build the search | 16:53 |
| rick_h_ | so in this case you pick category from the drop down, but there's no way to unset it like you could back in the checkbox day | 16:53 |
| rick_h_ | and then the replace was to "reset all the other checkboxes and use this new search" | 16:54 |
| hatch | ok thanks looks like you're right | 16:54 |
| rick_h_ | so it's more "do this whole search, no do this one instead, no do this one" vs the build a search "do this, now limit that by this other thing, and add this 3rd condition" | 16:55 |
| hatch | ok I can simplify this part of the filter code, looks like the bug is actually in the data the search widget is sending out | 16:57 |
| hatch | thx | 16:57 |
| hatch | we can re-implement this later, it's going to need to be refactored anyways | 16:57 |
| hatch | the cascading category stuff that is | 16:58 |
| rick_h_ | yea | 16:59 |
| hatch | darn UI changes | 17:00 |
| hatch | haha | 17:00 |
| * hatch gets his picketing signs "Down with Agile!" | 17:00 | |
| rick_h_ | lol | 17:01 |
| rick_h_ | "design spec document or bust!" | 17:01 |
| hatch | haha | 17:01 |
| rick_h_ | jujugui I'm going to cut out a bit early and comp my weekend time. I'll check in to help unblock hatch's branch, but be afk. | 17:02 |
| hatch | lata! | 17:02 |
| rick_h_ | maybe I'll tear down and rebuild my rack setup for the gui maas hehe | 17:02 |
| lazyPower | hatch: http://manage.jujucharms.com/tools/review-queue | 17:15 |
| hatch | lazyPower so how do you determine where in the queue it is? :) | 17:16 |
| lazyPower | hatch: Community take priority over canonical, otherwise its order in the queue. | 17:16 |
| lazyPower | as in, if its at the top, it goes first | 17:16 |
| hatch | Average wait time: 6 weeks | 17:17 |
| hatch | ouch haha | 17:17 |
| hatch | :) | 17:17 |
| hatch | do all updates to a charm take 6 weeks? | 17:17 |
| lazyPower | I had it cut down to 3 weeks. older items that come back into the queue after being nacked inflate that number | 17:17 |
| hatch | ohh | 17:17 |
| lazyPower | its not entierly accurate | 17:17 |
| lazyPower | but kinda sorta | 17:17 |
| hatch | FYI: the last time I submitted the ghost charm I was all gung ho and had time to do it, the review took a long time and then when the review came back it was months before I got back on it again - I'd imagine a similar problem to happen with the community too | 17:18 |
| lazyPower | hatch: its a byproduct of the solutions team having 8 moving targets to track | 17:20 |
| lazyPower | i dont disagree with you - i feel that whole heartedly | 17:20 |
| hatch | do updates to charms already in the store also enter this queue? | 17:21 |
| lazyPower | yep | 17:21 |
| lazyPower | Pretty much everything but the OpenStack charms enter this funnel | 17:21 |
| hatch | yikes - that's not going to be scalable | 17:21 |
| lazyPower | This is why automated testing and poliicy change is emminent. If you dont pass charm tests, it doesn't enter the queue. A bot updates your MP and its rejected from the queue | 17:22 |
| lazyPower | that way we are only looking at well formed, fully linted, and tested charms. | 17:22 |
| hatch | yeah that's a good idea | 17:22 |
| lazyPower | its on our radar, and we're working towards a solution. We just haven't reached terminal velocity with it yet. | 17:23 |
| hatch | right now are tests required to get into the store? | 17:23 |
| lazyPower | Since our testing story isn't that strong - we cant really enforce it. | 17:23 |
| hatch | ok good because mine doesn't have any tests :) | 17:23 |
| lazyPower | Once we have an established best practice, you bet. | 17:23 |
| lazyPower | we've already emailed the list back in December about the policy change and heard crickets on the thread. So chances are it will get another notice sent before its enforced. | 17:24 |
| hatch | I'll write tests when someone external uses the charm | 17:24 |
| lazyPower | We're looking to push ghost over WP as our demo charm. Because lets face it, ghost is a nicer platform if you're not sold on the 8 billion plugins for wp. | 17:24 |
| lazyPower | Ceppi is on review queue this week. Maybe give him a friendly poke when he's about that you're looking for feedback | 17:25 |
| hatch | it's also written in JS, so I'm not sure how a python test suite will work | 17:25 |
| hatch | :) | 17:25 |
| lazyPower | I tend to review charms that are getting a lot of attention over queue priority.. | 17:25 |
| lazyPower | Your tests dont have to be in python | 17:26 |
| lazyPower | so long as the tests are executeable and live in tests/ charm test will run them. | 17:26 |
| lazyPower | just make sure you have your dependencies mapped in 00-setup so they get installed on the test harness instance. | 17:26 |
| hatch | ok I'll have to revisit the testing procedure, I thought they had to be in python | 17:27 |
| lazyPower | we prefer it, but dont require it. | 17:27 |
| lazyPower | mostly because we have a strong python story in juju right now. A good majority of the store charms are bash, but you won't see us pushing bash - the second most popular language is python | 17:28 |
| lazyPower | followed by some of the specific Config Management frameworks... but by a wide margin | 17:28 |
| hatch | yeah - I'd just like to keep this charm all js because it's a full js stack app | 17:28 |
| lazyPower | Not a bad plan of action. | 17:29 |
| lazyPower | If you need anything, such as pointers in testing or what not dont hesitate to ping hatch | 17:29 |
| hatch | I figured it would be better for the ghost community | 17:29 |
| lazyPower | I'm going to bail and go code from the porch while my brats and steak char on the grill | 17:30 |
| hatch | :) enjoy | 17:31 |
| Makyo | jujugui small review/QA: https://github.com/juju/juju-gui/pull/343 | 18:01 |
| hatch | Makyo on it - heh the test is huge compared to the code | 18:01 |
| Makyo | Yeah, lots of container to prep. After il is removed, that can be moved to beforeEach/ | 18:02 |
| Makyo | Or even setUpInspector | 18:02 |
| hatch | Makyo so I'm guessing we just forgot to add this in when we did the switchover? | 18:05 |
| hatch | all done | 18:18 |
| Makyo | hatch, yeah, I think so. | 18:40 |
| hatch | ok now that the state>filter stuff is fixed | 19:01 |
| hatch | now to move the rendering trigger into the charmbrowser view | 19:01 |
| hatch | and boy is it nice when a rebase is just a simple FF | 19:01 |
| hatch | rick_h_ are you around by chance? I have pushed the new revision | 20:59 |
| hatch | jujugui anyone around for a review/qa? https://github.com/juju/juju-gui/pull/342 | 20:59 |
| rick_h_ | hatch: will look tonight. | 21:50 |
| rick_h_ | hatch: updates go ok? | 21:50 |
| hatch | thanks | 21:50 |
| hatch | yeah works well | 21:50 |
| rick_h_ | hatch: quick run through leads to just one question on the shouldRender stuff | 21:54 |
| rick_h_ | hatch: will QA probably after dinner time | 21:54 |
| hatch | sure, replied to one, just reading the other now | 21:55 |
| rick_h_ | hatch: and replied, yay interwebs | 22:01 |
| hatch | haha | 22:05 |
| hatch | replies replies replies | 22:06 |
| hatch | oops lint | 22:18 |
| rick_h_ | hatch: ok, any feedback on the name suggestion? | 22:34 |
| hatch | umm sorry reviewing huws branch, looking | 22:34 |
| rick_h_ | hatch: all good thanks for peeking at his branch | 22:34 |
| hatch | don't like it, I replied actually :) | 22:34 |
| hatch | https://github.com/juju/juju-gui/pull/342#discussion_r13057884 | 22:34 |
| rick_h_ | right, didn't see it as a direct comment sorry | 22:35 |
| rick_h_ | see, you should never not render. You might not update an existing rendered view though | 22:35 |
| rick_h_ | oh well, it's a naming thing. Don't want to cause a stink over it but as an api it's kind of meh in my head. Thanks for the other updates. Will QA and :+1: after that fact | 22:36 |
| hatch | hmm - hmmmmmmmm | 22:39 |
| hatch | rick_h_ I'm still trying to convince myself of the name change :) In the mean time, do you know if huwshimi will be working today? | 22:52 |
| rick_h_ | hatch: I believe so | 22:56 |
| rick_h_ | hatch: as far as I know | 22:56 |
| hatch | ok cool, I just finished his review/qa | 22:57 |
| hatch | I'll leave IRC on in case he has any questions | 22:57 |
| rick_h_ | hatch: cool | 22:57 |
| hatch | https://www.trulyergonomic.com/store/index.php | 22:59 |
| hatch | that's a pretty cool looking keyboard | 22:59 |
| hatch | looks like it might be a good layout for coding | 23:00 |
| rick_h_ | yea, the big thing is the lack of windows key that I use for my window manager | 23:01 |
| rick_h_ | my kenisis works well. If I go off of it for a few weeks my wrists hurt, going back to the kensis helps | 23:01 |
| rick_h_ | I do have a kensis split I'm going to try out for travel arriving wed | 23:01 |
| hatch | there is that odd juju looking button in the middle top | 23:02 |
| rick_h_ | https://www.kinesis-ergo.com/shop/freestyle2-for-pc-us/ curious how that works out | 23:02 |
| rick_h_ | yea, but that's not going to be a decent keycombo key | 23:02 |
| hatch | oh no | 23:02 |
| rick_h_ | hitting that plus hjkl to move windows will be awkward | 23:02 |
| hatch | haha yeah it would | 23:02 |
| hatch | I'd like to give a kinesis a try but at $300 it's an expensive test | 23:03 |
| hatch | haha | 23:03 |
| rick_h_ | anyway, I've seen it a few times but can't get convinced enough to try it out | 23:03 |
| rick_h_ | well you should let me know. I'll send you my older model to try out | 23:03 |
| rick_h_ | I've got an old ebay one I used to justify getting the nicer new one | 23:03 |
| hatch | everyone I know who uses one loves it, I should really just bite the bullet | 23:03 |
| rick_h_ | but yea, it took me over a year of eye'ing it before I could pull the trigger. Most expensive keyboard I've owned by far | 23:03 |
| rick_h_ | exactly, not really many I know that rant against it once they get over the learning curve | 23:04 |
| rick_h_ | it feels a ton different for sure | 23:04 |
| hatch | heh, not sure what I'd use as a macro though | 23:05 |
| hatch | I wonder what people set up macros in their keyboards for | 23:05 |
| hatch | it's been thundering for almost 5 minutes non stop | 23:07 |
| hatch | very weird | 23:07 |
| hatch | one continuous rumble | 23:08 |
| rick_h_ | yea, I don't use the macros | 23:08 |
| rick_h_ | it is cool to reprogram keys at the keyboard level though | 23:08 |
| rick_h_ | "this is an alt key regardless of wtf I plug it into" | 23:09 |
| rick_h_ | and not worry about os level mappsing | 23:09 |
| hatch | http://weather.gc.ca/lightning/index_e.html?id=WRN#mapTop | 23:09 |
| hatch | heh | 23:09 |
| hatch | https://twitter.com/PQuinlanGlobal/status/471063686694445056 | 23:09 |
| hatch | purple must mean bad things | 23:10 |
| hatch | here comes the hail https://twitter.com/PQuinlanGlobal/status/471065379062571008 | 23:11 |
| hatch | well at least I wasn't going nuts https://twitter.com/PQuinlanGlobal/status/471064268901580801 | 23:11 |
| hatch | good morning huwshimi | 23:12 |
| huwshimi | Morning | 23:12 |
| huwshimi | hatch: Any ideas about this bug? https://bugs.launchpad.net/juju-gui/+bug/1323199 | 23:13 |
| _mup_ | Bug #1323199: Dropping unplaced units errors <juju-gui:New> <https://launchpad.net/bugs/1323199> | 23:13 |
| hatch | https://twitter.com/PQuinlanGlobal/status/471065968290979840 heh, yep it's comin down hard | 23:14 |
| hatch | huwshimi looking | 23:14 |
| hatch | huwshimi I can reproduce, looking into it now | 23:18 |
| huwshimi | hatch: You can see the line I tracked the error back to in that bug | 23:18 |
| hatch | looks like the issue is that https://github.com/juju/juju-gui/blob/develop/app%2Fstore%2Fenv%2Fgo.js#L930 is returning a string not an object like it used to | 23:20 |
| hatch | hmm that's not ie | 23:23 |
| hatch | it* | 23:23 |
| huwshimi | hatch: Could it have anything to do with this branch? https://github.com/juju/juju-gui/pull/339/files | 23:27 |
| huwshimi | hatch: Note the change from id to unit. | 23:27 |
| hatch | so the issue is that the unit no longer has all of the attributes it once had | 23:28 |
| hatch | looking at that pr | 23:28 |
| hatch | yeah that does look like the problem | 23:32 |
| hatch | huwshimi this should be `attrs.unit.id` https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fserviceunit-token.js#L132 | 23:33 |
| hatch | man files are hard to find....half of the views are under /widgets | 23:33 |
| huwshimi | hatch: A brilliant. Want to land a branch to fix that or do you want me to? | 23:34 |
| huwshimi | I could also land it as a drive-by in my next branch | 23:35 |
| hatch | nope I'm done for the day today | 23:35 |
| hatch | cleaning the kitchen atm :) | 23:35 |
| huwshimi | hatch: Sure, I'll do it :) | 23:37 |
| huwshimi | hatch: Thanks for figuring it out! | 23:38 |
| hatch | no problem | 23:41 |
| hatch | I see you saw that I reviewed your branch - if you have any questions about that just lemme know | 23:43 |
| huwshimi | Sure, no problems. | 23:44 |
| huwshimi | hatch: The funny thing is you reviewed the branch that added all these click handlers and now you don't like the names :) | 23:48 |
| hatch | I have more context now | 23:48 |
| hatch | **excuses level 100 achievement unlocked** | 23:48 |
| huwshimi | hehe | 23:49 |
| hatch | lol | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!