=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
urulama | luca: hey, you there? | 12:03 |
---|---|---|
luca | urulama: hey | 12:22 |
=== dimitern_ is now known as dimitern | ||
hatch | morning | 13:49 |
rick_h_ | hatch: can you peek at huw's branch this morning please? | 13:51 |
hatch | on it | 13:52 |
hatch | had to drive the rents to the airport at an ungodly hour this morning | 13:52 |
hatch | lets see how long I last :D | 13:52 |
rick_h_ | lol | 13:52 |
hatch | also had to climb into the attic this morning | 13:53 |
hatch | insulation and nails....awesome environment | 13:54 |
hatch | :D | 13:54 |
rick_h_ | death trap, at least it's not summer when it's melting degrees up there :P | 13:54 |
hatch | true true | 13:55 |
hatch | very cold though :) | 13:55 |
hatch | rick_h_: is ci down? | 13:55 |
hatch | yup | 13:55 |
hatch | *itch itch itch* damn insulation | 14:10 |
hatch | uiteam I still need two reviews and qa on https://github.com/juju/juju-gui/pull/670 | 14:16 |
hatch | last night I started prepping my old mac mini to be converted into an Ubuntu server | 14:17 |
hatch | not sure what I'll use it for | 14:19 |
hatch | rick_h_: I checked out huw's branch and resolved the issues and pasted the diff in the PR | 14:38 |
rick_h_ | hatch: ty | 14:39 |
hatch | github is so handy sometimes - pasting a formatted diff right into the comments of a pr | 14:39 |
hatch | http://blog.ghost.org/roon/ interesting... | 14:43 |
hatch | I found some old GUI pictures from a couple years ago when cleaning out the mini last night :) | 14:47 |
hatch | wow has there been a lot of UI changes lol | 14:47 |
rick_h_ | :) | 14:48 |
urulama | hatch: do share :) | 14:48 |
hatch | urulama: I'll have to get them later I didn't get a chance to get all my stuff uploaded to the NAS before bed | 14:48 |
hatch | I'll try and finish that up tonight so I can get them | 14:48 |
hatch | it was grey, yellow, red | 14:48 |
urulama | hatch: np, just curious :) | 14:49 |
hatch | :) | 14:49 |
urulama | hatch: http://www.rothkoeverywhere.com/wp-content/uploads/2011/05/99p-Store-Yellow-Red-Grey-600x800.jpg | 14:49 |
hatch | but last night I learnt that the Synology nas has a cloud sync tool which will backup the synology nas to google drive | 14:49 |
hatch | pretty excited to give that a try | 14:49 |
hatch | true local and remote backups | 14:50 |
hatch | :) | 14:50 |
urulama | hatch: wow! that's nice | 14:50 |
hatch | yeah atm I have my synology nas with a local external backup so Local > NAS > Backup | 14:50 |
hatch | but I lose it all if the house goes up and I haven't manually backed it up to the cloud | 14:50 |
hatch | having it Local > NAS > Backup > Cloud will be awesome | 14:51 |
hatch | might end up costing me $2/mo though (I have a lot of junk) | 14:51 |
hatch | :) | 14:51 |
hatch | luca__: I'm not sure I agree about requiring users to clear the issues in the inspector | 14:54 |
hatch | what if they have a ton of failed units but just want to leave them be while they work on something else | 14:54 |
hatch | ahh I can just reply via the ticket :) | 14:55 |
luca__ | hatch: I suppose, but whats the point of notifications if it doesn’t track errors? | 14:57 |
luca__ | hatch: all other notifications are notifying the user about something that has completed or an upgrade | 14:58 |
luca__ | hatch: the user can choose to either action them or not | 14:58 |
luca__ | hatch: but I’m not sure it’s the same for errors | 14:59 |
luca__ | hatch: In our panel, we group errors so if 10 units of MySQL error out then you only get 1 notification | 14:59 |
hatch | I suppose the grouping does make identical errors less of an issue | 15:08 |
hatch | would the GUI level issues go here as well? | 15:08 |
hatch | things like "cannot fetch charm data" | 15:08 |
luca__ | hatch: for now I think so, yes | 15:20 |
hatch | luca__: so those would need to be dismissed within the notifications then | 15:22 |
hatch | so is that interaction then a little confusing? | 15:22 |
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
hatch | teslanick: I decided my approach will be a 'executor' function which is passed in functions to execute - it'll execute that function every time it's called unless it's passed another one then it'll start to call that one instead | 18:58 |
rick_h_ | hatch: ok, standup? | 18:58 |
hatch | without doing manual recompilation it's just not possible in anything I've found | 18:58 |
hatch | rick_h_: joining | 18:58 |
teslanick | hatch: So something that's like var e = executor(someFunc); /* later */ e.swap(someOtherFunc); ? | 18:59 |
hatch | teslanick: yeah | 19:17 |
hatch | trivial | 19:17 |
teslanick | Seems difficult to reason about | 19:18 |
hatch | The idea is that you have a set of records, you don't know what you need to process each record ahead of time, once the program accepts the record it passes it to its executor if the executor can't make any sense of the record the program takes what it does know about the record and swaps the executor | 19:21 |
hatch | (yes this can all be done with a prefixed conditional) | 19:21 |
hatch | (but like I said, this is just a dumb academic idea) | 19:21 |
hatch | the program execution could be thought of as a kid trying to put a round peg through one of those balls with the different shapes :) | 19:22 |
teslanick | It sounds like you could use some sort of pattern-matching middleware concept to achieve the same idea. | 19:22 |
hatch | the program would - as a kid would - become smarter about the data which was passed in to choose the correct executor | 19:23 |
=== tvansteenburgh is now known as tvan-afk | ||
hatch | teslanick: you definitely wouldn't write a real program like that :) | 19:38 |
=== kadams54 is now known as kadams54-away | ||
jcastro | rick_h_, dumb question | 21:11 |
jcastro | when does juju.ubuntu.com switch to jujucharms.com? | 21:11 |
hatch | that's not a dumb question at all :) | 21:17 |
rick_h_ | jcastro: talked with luca on it monday. We're working to bring up the blog on the next release and they feel that's about the last thing required before bringing it down. | 21:49 |
jcastro | ack, thanks | 21:49 |
rick_h_ | jcastro: we've still got some stuff to do on pulling in feeds from insights/etc, but luca feels close enough | 21:49 |
rick_h_ | jcastro: so 1week or less? they control it | 21:49 |
jcastro | awesome | 21:49 |
jcastro | and the deploy #s? | 21:49 |
jcastro | when do you anticipate those being correct? | 21:50 |
rick_h_ | jcastro: next release, branch on that landed today I think | 21:50 |
* jcastro nods | 21:50 | |
rick_h_ | ah sorry, landed yesterday but yea still next release | 21:51 |
jcastro | ok you are 2 for 3 | 21:51 |
jcastro | last one... | 21:51 |
jcastro | juju publish? | 21:51 |
rick_h_ | long road, end of cycle. We'll have parts of it before then, like gating, but no full workflow until closer to end of cycle | 21:52 |
jcastro | ack | 21:52 |
rick_h_ | it'll land in chunks as part of other work to the charmstore through the cycle as needed, but no single 'turn on switch' any time soon | 21:53 |
huwshimi | Morning | 21:58 |
hatch | mornin huwshimi | 21:58 |
hatch | I posted a patch to your PR for the bug you were having | 21:58 |
hatch | s/bug/issue | 21:58 |
huwshimi | hatch: Ah brilliant thanks for that! | 21:59 |
hatch | np, turns out I caused one of the issues :D | 21:59 |
huwshimi | hehe | 22:00 |
huwshimi | hatch: Should I add "window.flags = {};" to the afterEach to clean up then? | 22:00 |
huwshimi | oh, no I can do it before then done in the test | 22:01 |
huwshimi | nevermind | 22:01 |
hatch | huwshimi: in the event that the test fails and it doesn't hit that callback then flags will not be reset | 22:01 |
hatch | so it'll have a compound failure | 22:01 |
hatch | so putting it in the afterEach isn't a horrible idea | 22:02 |
huwshimi | hatch: Ah yeah, good call | 22:02 |
huwshimi | Makyo: How far have you gotten with the multi-user stuff? I wasn't sure how to switch users... | 22:23 |
Makyo | huwshimi, just getting to it now, had appt. For the card with both our icons on it, you can apt-add-repository ppa:juju/devel && apt-get update; apt-get upgrade | 22:24 |
Makyo | That will get you a juju that can work with multiple users. | 22:24 |
Makyo | For switching users, we'll have to log out and log back in, since that's the first command we send over the WS | 22:24 |
huwshimi | Makyo: Oh, how do you logot? :) | 22:25 |
huwshimi | *logout | 22:25 |
huwshimi | (from the console) | 22:25 |
Makyo | huwshimi, ATM I think all console interaction happens as the admin user, or at least whichever user is in the jenv file, but still researching that. `juju help user` shows the user creation/modification stuff. | 22:28 |
huwshimi | Makyo: Yeah, I couldn't find anything to the contrary | 22:30 |
=== kadams54 is now known as kadams54-away | ||
huwshimi | Makyo: Logging in from the gui works at least | 23:04 |
=== kadams54 is now known as kadams54-away |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!