[00:00] haha no it's fine, it makes sense [00:00] Also the card "When constraints are hidden, they still show upon selecting the machine." is that bug you're seeing or do you want it to still show for the selected machine? [00:01] added [00:01] huwshimi: so if you hide containts from the list, but select a machine [00:01] they should show up, at least per the designs [00:01] it's a bug I'm seeing currently, hiding constraints will never show them even when you select a machine token [00:01] Ah yes, I understand [00:02] "disable add container for anything but MAAS" is a massive, massive card [00:03] huwshimi: :) well it's a few cards there, but yes. It's one of the 2 big paths this week. [00:03] that path and the ecs/data binding conflict path [00:03] and then qa/polish === urulama-afk is now known as urulama [11:12] morning party people === urulama is now known as uru-bot === uru_ is now known as urulama [12:55] any Canary users? might want to skip updates right now. Its unstable for me. [13:19] jrwren: thanks, good to now [13:19] know [13:30] jujugui I need one review (no qa needed) https://github.com/juju/juju-gui/pulls [13:30] https://github.com/juju/juju-gui/pull/524 [13:31] lol [13:31] hatch: looking [13:31] rick_h_: thanks - the code is pretty cryptic without the whole picture in your head unfortunately [13:31] hatch: ok, I'll just wander around confused a bit and ask lots of questions :P [13:32] haha [13:42] rick_h_: you can remove a unit from a machine? [13:43] hatch: certainly [13:43] hmm I never tested that one [13:43] or made any changes to that...lemme see if it works [13:43] hatch: yea, sec let me get the visuals on that [13:44] hmm you can't remove uncommitted units [13:44] does this work for you? https://drive.google.com/drive/u/1/#folders/0Bzj8yHKHrx6pNkVUTkNPd3RWNTQ/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM/0B7XG_QBXNwY1aVh1cC0wU0JRaW8 [13:45] this was part of that talk around the more menu on each unit in the container view [13:45] hmm removing a unit via the inspector also removes the host machine in sandbox [13:46] yea, I can't drop another unit on the root container atm to get the two units listed and see if the more menu appears for each [13:46] but I'm guessing it's nothere, but yes, you can remove a unit from a container/machine via the container view [13:47] hatch: so I'd suggest we get the root container thing fixed up so we can QA and identify any bungs around that [13:47] I'd really like to get this landed - it's been conflicted 3 times already :) [13:47] hatch: understood :/ I guess it's progress and we need a couple of things worked on/fixed for the delete scenario [13:48] hatch: ok +1 on landing with follow up card created for 'updating machine token when unit is deleted from container view' [13:50] yeah atm you can't delete a unit only the container [13:50] and you can't delete the container because the unit is assigned [13:50] hah [13:51] wheee [13:51] removing a unit via the inspector breaks the mv [13:51] *sigh* filing a bug [13:52] :/ [13:57] https://bugs.launchpad.net/juju-gui/+bug/1364956 [13:57] Bug #1364956: Removing a unit via the inspector creates a sticky remove unit command in the deployer bar [13:58] ty, updated [14:02] rick_h_: testing this stuff in a real env is really difficult because it allows us to do things that aren't supported that put things into a funky state [14:02] like creating lxc containers in ec2 for instance [14:02] it 'works' but then can't delete it because it can't communicate with it [14:02] so maybe we should make sure we have the proper functionalities enabled [14:02] / disabled [14:03] hatch: yes, agreed. frankban is working on that card now [14:03] oh, cool [14:04] rick_h_: think we can get an orange box to test this on pre-release? [14:04] even if they just plugged it into the wall in London? :) [14:04] hatch: well luca is getting one but not sure when. [14:04] hatch: but if I can get caught up I want to get my MAAS setup turned on which we could test it on [14:04] ahh - I'm just thinking on how we can test the maas stuff [14:04] oh alright [14:05] hatch: yea, the idea is the maas setup I have at home. [14:05] jcsackett: you betta today? [14:05] http://maas.jujugui.org/ [14:05] but it's down for the count atm [14:05] hatch: "better" may be overstating the case, but i'm here. :p [14:05] jcsackett: well then! drink lots of beer [14:05] that's how you fix a cold right? [14:06] somehow i doubt that would have the desired effect. :p [14:06] haha [14:06] jcsackett: your card in review, did that land already? [14:07] and....did you want the card "unable to place a unit on a root container" it was caused by the "do not drop on deleted containers" branch [14:07] hatch: yes, it landed, and sure. [14:07] ok cool, I'm just trying to pick my next :) [14:08] jcsackett: the card there is important. If you need to run please ping and handoff. [14:08] jcsackett: and glad you're feeling able to move [14:08] rick_h_: i don't anticipate crashing today, but if i feel like i'm going down for the count i'll let people know. [14:08] jcsackett: ty much [14:09] rick_h_: you talking about the card hatch just mentioned, or the one i'm sharing with brad at the top of the board (that's actually marked important?) [14:10] jcsackett: the one hatch mentioned, though I'm eager to hear about what's up with the one you're sharing with brad. [14:10] rick_h_: i can catch you up on that now if you like, or in standup. [14:10] jcsackett: all good. Is that done and have a review? [14:11] jcsackett: just waiting to land/deploy? [14:11] rick_h_: needs a review from marco (who i've just pinged in eco); then charmworld itself needs updating, then deployment. [14:11] the charmworld update/deploy part is a second card. [14:11] jcsackett: there's no MP linked in the card external link or review tags. [14:12] what's the charmworld update needed? [14:12] oh shoot I didn't send out my comment on that branch [14:12] damn LP -> github differences [14:13] rick_h_: i've updated the card, but to land we need review outside of this team. marco just acked. [14:13] jcsackett: cool [14:13] rick_h_: once charmworldlib is updated and the 0.4.2 release is made, then bac has an update to use that that i can review and land. then the deploy funtimes. [14:13] ic, so the charmworld update is the dep updated [14:13] jcsackett: gotcha ty for the catch up :) [14:15] rick_h_: yw. [14:26] jujugui it looks like a fresh utopic lxc only has python3 in it. So going to add some stuff to the board for checking on and updating quickstart and our charm. [14:27] jujugui probably first with just addingn py2 as a dep and then looking at updating from there. [14:27] wow that took a while....3's been out for what? 7 years? :P [14:27] mhilton: thanks for the pointer there on the changes. Glad quickstart seemed to get a ways into working before it broke in py3 [14:28] hatch: well there's a LOT of python code to update before the distro can change the default [14:28] hatch: but yea, it's been 5yr ish I think? [14:28] it's actually because everyone changed to node [14:28] though everyone agrees py3 didn't really get usable until 3.2 [14:28] lmao [14:28] so there was noone to port the code [14:28] rick_h_: Except it isn't python 3, at least no on my machine [14:29] mhilton: oh? I saw utopic and assumed it was a fresh-ish install with py3 [14:29] mhilton: ok, can you update the bug with the python version info as well please? [14:29] mhilton: doh, yea the traceback shows 2.7 [14:30] yeah sure. I installed it just before the utopic beta came out [14:30] mhilton: ok, will keep chasing after your bug there. [14:30] jrwren: quick hangouts? [14:30] urulama: yes. [14:30] jrwren: https://plus.google.com/hangouts/_/canonical.com/jay-uros?authuser=0&hceid=dXJvcy5qb3Zhbm92aWNAY2Fub25pY2FsLmNvbQ.228npoderqhjtlfek7mqq3a0p4 [14:32] and... chrome crashing. [14:33] Makyo: your card is in review right? [14:33] jrwren: :) [14:33] urulama: how I'm in this room with myself. [14:33] jrwren: khm. do use the link from the invite then :S [14:42] * rick_h_ heads back to the house [14:47] rick_h_: quickstart depends on python2, so it should be ok in utopic. I am more concerned about the versions of the websocket-client and pyjuju-client [14:48] rick_h_: also, I am not sure about the charm vs utopic. AFAIK we only support LTS releases for the charm (so precise and trusty) [14:49] mhilton: can you add to the bug the versions of the quickstart dependencies? e.g. python-websocket and python-jujuclient [14:50] luca__: I hate the container column....fix it plz :P [14:50] maybe pictures of puppies can go there? :) [14:51] jujugui call in 10 [14:54] frankban: +1, I've got a utopic lxc to tinker with and check it out. [14:54] hatch: what do I need to fix? :D [14:55] luca__: iunno it just sits there...empty....waiting...longing for someone to love it [14:55] hatch: well, it should never be empty…let me have a look [14:55] hatch: I think there is a bug for that somewhere [14:56] well it's not "empty" [14:56] but it has, say 2 containers [14:56] and about 1000x250px of whitespace [14:56] (if I shrink my browser) [14:57] hatch: well, yeah but thats because you haven’t figured best pratice and nested all of your services in endless containers…. :P [14:57] hahaha [14:57] it's not even possible!!!! [14:57] hatch: yeah, rick_h_ told me [14:57] sad...really [14:57] :'( [14:57] hatch: I think if we had known that from the start we would of come up with a different solution [14:57] guihelp: one thing I've noticed as I work on standardizing constraints is that we use the label "disk" in some places and "root-disk" in others… I'd like to change it all to one label, but that may require a data migration, which I've never dealt with in juju world. [14:57] anyways....I was just joking around, but it would be nice if something could go there - I have no idea what though [14:58] hatch: good thing we didn’t go with the boxes model because you would of just had big boxes everywhere o.O [14:58] hatch: I’m +1 on the puppies [14:58] yusssssss [14:58] kadams54: data migration? the constraint key is root-disk isn't it? [14:58] so the stuff which says 'disk' would just be a label [14:58] hatch: fluffy unicorns? [14:58] kadams54: we don't store that data, so no migration should be involved [14:58] urulama: haha [14:59] urulama: can unicorns be fluffy? [14:59] hatch: not everywhere. In some places it's "disk" [14:59] hatch: we can review it very quickly in brussels :) [14:59] I thought they were lean mean murdering machines [14:59] lol [14:59] hatch, luca__: Despicable me :) http://media-cache-ec0.pinimg.com/736x/8a/5d/f5/8a5df52b9773d53c1cc6a1d7ab6a827a.jpg [14:59] hhahahaha [14:59] oh I love that show [14:59] hatch: urulama https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#q=fluffy%20unicorns&safe=off [14:59] that part made me roar laughing on the plane....ppl looked at me funny [15:00] luca__: :D :D :D [15:00] luca__: so you're thinking about animated gifs for background, right :D [15:01] kadams54: the name of the constraint in juju is "root-disk", we should always send that. The label we show can be either "disk" or "root-disk" and I don't have a string opinion, but I agree it should be consistent in the GUI. I remember we had a map/array storing constraints keys and labels somewhere [15:01] frankban: call time [15:42] guihelp: Looking for reviews and QA on https://github.com/juju/juju-gui/pull/528 - there's also a TODO in that code that's sort of an open question about hardware data vs. constraints. [15:46] kadams54: you are right, while constraints are something we request new instances to conform to, hardware characteristics are actual values (arch, mem, cpu-cores etc.) describing existing machines [15:47] Yeah, it just got confusing with grepping through source and test code looking for instances of "disk" that needed to be changed to "root-disk". [15:47] I accidentally changed a number of instances that dealt with hardware rather than constraints before I realized what was going on. [15:48] kadams54: yeah that's unfortunate [15:48] Also the cpuPower vs. cpu-power just makes my obsessive-compulsive side twitch :-) [15:58] Makyo: do you know why https://github.com/juju/juju-gui/blob/master/app%2Fviews%2Ftopology%2Fservice.js#L1189 model here would be undefined but the bounding box still exist? === hatch__ is now known as hatch [16:00] juju-gui: have fun, viva MV release ;) [16:02] kadams54: heh, well that's thanks to pyjuju vs go juju :) [16:03] uru-bot: night! :) [16:06] hatch, no, not quite sure why that would happen [16:07] Makyo: hmm ok will keep digging [16:07] breakpoints ahoy!!! [16:07] * rick_h_ goes to nuke up some leftover lunchables [16:13] luca__: https://bugs.launchpad.net/juju-gui/+bug/1365053 [16:13] Bug #1365053: Add units dialogue on pre deployment inspector is confusing [16:14] hatch: that is the correct behaviour. It should auto place that machine, I was going to talk to rick_h_ about it because it’s quite hard to explain. [16:14] hatch: it should have a 1 in the input field [16:15] ok so it is broken now? [16:15] hatch: at the moment you can put 5 in the input field and click auto place and it will give you 5 units and you’ll be left with 1 unplaced unit [16:15] rick_h_, hatch: Looking at the "Clicking on the inspector after closing shouldn't reset the help text" card - I remember this coming up in IRC after EOD for me. [16:15] hatch: yeah [16:15] hatch: the field should start with 1 unplaced unit which is the 1 listed. [16:16] luca__: ok but that unplaced unit is already created so we can't auto place it because they scaled up... [16:16] that's a separate interaction [16:16] rick_h_, hatch: just to be sure… what this card means is the "Your service has been added. Configure using the tabs below." text, correct? [16:16] hatch: yeah, thats the problem that I’ve been trying to think through, I think it’s worth talking through because it’s pretty complex [16:17] luca__: I think my problem with it is that it looks like the add-unit dialogue is part of the inspector instead of a separate dialogue because it's pre-opened [16:18] maybe just a colouring thing would fix that - make the bg lighter for that section... [16:18] hatch: are we talking about the same bug? [16:18] kadams54: yeah - if you click dismiss, it should stay dismissed even on subsequent openings [16:19] maybe? have time for a call? [16:19] :) [16:19] hatch: thanks [16:19] hatch: sure, got a link [16:19] ? [16:19] incoming [16:19] rick_h_: care to joing? [16:19] luca__: rick_h_ https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 [16:27] hatch: i was wrong, icons on the root container still seem to have some goofiness. they worked sometimes, not always. [16:29] kadams54: otp atm will catch up in a sec [16:29] rick_h_: no worries, hatch answered my question [16:31] ah cool then [16:31] heading out for a run, bbiab === fabrice is now known as fabrice|dinner [16:38] jcsackett: ok we can investigate once your fix has landed - there appears to be a unit data race condition [16:38] I created a bug..... [16:38] wheee [16:38] umm looking [16:40] ahh I can't find it [16:40] anyways when you visit a /machine url it causes bustedness [16:40] https://bugs.launchpad.net/juju-gui/+bug/1364622 [16:40] Bug #1364622: Hardware information never becomes available when creating new machines on ec2 [16:40] ^ jcsackett I think this is a symptom of the same issue [16:48] hatch: what's the best way to wait for an event (e.g. an attribute change) before proceeding with the function in YUI? [16:48] frankban: it depends what you have access too [16:48] do you have the model? [16:48] or the class with the attribute on it? [16:48] if so... [16:49] myClass.on('fooattrChange', function(e) { ... } ); [16:49] where "fooattr" is what your attribute is called [16:49] hatch: yes, but that's asynchronous [16:50] I think I need more context [16:50] call? [16:50] standup? [16:50] frankban: can you noop if the function isn't passed the change event object? just verify it's bound or whatever? [16:51] frankban: rick_h_ I'm in the standup room [16:52] rick_h_, hatch: I am in a view initializer, and I can't proceed until a specific value is set to model attribute I have access to. So I have two options: 1) look at all the places the view is created and put the view instantiation in a callback (reacting to an event) or 2) sync wait without doing nothing in some way [16:53] frankban: so I'd init the view, do what can be done, and setup a watch on the model for the value if it doesn't exist yet [16:53] rick_h_, hatch: to be clear, we have to wait for juju-core response to EnvironmentInfo before being able to use the machine view, because only at that time we know what containers are supported [16:54] joining the call? [16:54] frankban: ok, so I'd go with a default of disabled, and only open it up once we had a value? [16:54] yeah that [16:54] the hope being that by the time the user deploys something, or goes through and creates a machine it would be done/back [16:55] rick_h_: so, the machine view is disable until we have the value? what if the user reload the machine view? should we redirect to the service view? [16:55] not MV but just the add container buttons [16:57] frankban: the only thing we're trying to protect the user from doing is trying to create a container only to get an error or broken state back from juju. [16:58] frankban: you can create a flag in the mv which says "enable container stuffs" on load it checks that flag to see if it should show it, if not, it attaches a listener for that flag to enable it in the future [16:58] rick_h_: there are two ways to create a container: using the button and dragging a unit to an existing machine [16:59] hatch: that's a possibility [16:59] frankban: so thinking this through, we talked about having a 'featured enbaled/disabled' object [16:59] frankban: and so we'd default to one that is not enabled in real environments, the create machine feature is disabled [17:00] frankban: and once we got the answer of provider back from juju, we'd need to be able to notify users that the provider (and thus features enabled/disabled) has changed and update their UX accordingly [17:01] rick_h_: I think I have a plan, the UX will change from an initial state in which the header shows something like "checking sub-containers support" to the current one or a third one stating "sub-containers not supported" [17:02] frankban: oh that's interesting. I hadn't thought about expressing the 'checking' idea out to the user. [17:02] frankban: I worry about a flashing message the user can't read/get back to but we can try that out [17:02] frankban: how long does it take for juju to respond with support? [17:03] rick_h_: it's just a fast request/response [17:04] rick_h_: so I'd expect that if the user lands to the service view, he will never see the message. if he refreshes the machine view he can see the "checking" message, but I am not sure it matters if it fastly disappears [17:05] frankban: sounds good to try out [17:06] rick_h_, hatch: in theory it can still be racy, e.g. [17:06] val = env.get('providerType') [17:07] if(!val) {env.on('providerTypeChange', func...)} [17:08] rick_h_, hatch: in theory the provider could be set between line 1 and 2 [17:08] no it can't [17:08] js is still synchronous [17:09] the get call is synchronous, and so is the if check [17:09] hatch: so it's asynchronous but YUI events bubbling is in the same thread, correct? [17:10] hatch: so the event can be notified only after the current function completes, is it right? [17:10] I don't think it'll pause and change stacks mid-if statement like that. [17:10] frankban: correct [17:10] frankban: I think it's pretty safe to use [17:10] hatch, rick_h_: good then, thank you [17:10] something needs to yield the thread for the async loop to run [17:11] excellent [17:13] done for the day, have a good evening! [17:13] have a good evening frankban [17:16] jujugui still need one QA/review on https://github.com/juju/juju-gui/pull/527 [17:16] on it [17:19] Thanks [17:20] Makyo: one comment b4 I qa [17:21] on the pr [17:22] Oh, I thought that's what remove did. I can hunt down further. [17:22] New to widgets. [17:26] its' a view [17:27] :) [17:27] Makyo: you can call `this.destroy()` and it'll go through it's destroy cycle [17:27] but I thought that we kept reference to these tokens somewhere in the mv as well [17:27] so something in the mv will need to listen for any token destroy events and then remove it from the list [17:28] Ah, lright. [17:32] jujugui: i need two reviews on https://github.com/juju/juju-gui/pull/529 [17:32] jcsackett: on it [17:33] Makyo: FYI, there's code in the MV that will remove the token from the internal cache if the corresponding entity (machine, service unit) is deleted from the DB. [17:34] Makyo: IIRC, there's already code to delete from the DB as part of your changes? [17:34] kadams54, okay, thanks. Will look into that. [17:34] Yes. [17:34] Then you can ignore hatch :-) [17:35] But he's so loud! [17:35] hatch, kadams54 I'll do a bit of research and ensure that's the case. [17:35] :) [17:36] Yeah, shouldn't be too hard to confirm with a breakpoint [17:36] jcsackett: one comment on pr before I qa [17:38] Makyo: look at _removeUnit (called from _onUnitRemove) in machine-view-panel.js, line 401 [17:38] hatch: given that parentId === selected when you drop on the container header as well, i think i prefer the explicit toggle. [17:39] Makyo: it looks like it calls a destroy on the token in addition to removing it from the internal cache. This is all triggered on a DB delete, as setup on line 147. [17:39] ok good point [17:39] qa'ing now [17:39] Makyo: So I think you can also ignore hatch's comment in the PR :-) [17:40] Makyo: I think the only places it needs to be removed from are the ECS and the DB. [17:40] Makyo: kadams54 in that case, the remove() call can be removed and a comment added to say where/what is happening [17:40] Yep, checking that now. [17:41] jcsackett: I'll do the second review/QA on your PR [17:44] kadams54: awesome, thanks. [17:47] kadams54: you need reviewers for your PR, yes? [17:47] jcsackett: correct [17:47] on it. [17:51] hatch, kadams54 PR updated with comment [17:51] Makyo: looks good, qa'ing [17:53] Makyo: qa issue added to the pr [17:55] Ah hell. [17:55] I thought that was managed by databinding. [17:56] I knew this branch was too easy. [17:56] Makyo: hah sorry - I didn't do that stuff in the inspector, I too thought it was databound [18:10] guihelp: in order to make sure the help text stays dismissed, my first inclination is to use a cookie. That said, there doesn't seem to be much else in the app that is cookie-based, so not sure if that's a bad sign or if I'm just blazing new territory :-) [18:11] On second pass, I may add a 'dismissed' class instead, but I'm still curious about the lack of cookies. [18:12] kadams54: qa notes on your PR. [18:18] jcsackett: thanks [18:25] kadams54, don't we use cookies for hiding onboarding? [18:25] Makyo: the only onboarding I've worked on is hidden/shown depending on the number of machines, not any express user preference. [18:26] But the "Getting to Know You" onboarding might be a good place to look at. [18:26] Oh, that was in local storage. There's an onboarding key and a force-onboarding key. [18:35] kadams54: set a flag on the model for the service [18:35] inspector to model is a 1:1 relationship so it's the best place to put it [18:36] and really easy to implement :) [18:41] jcsackett: got a sec to chat? [18:41] rick_h_: sure, just a moment. [18:41] standup room? [18:42] hatch: kadams54 what about just showing it on ghost/first run and not on any others? [18:42] hatch: kadams54 is there any way to tell a first auto launch from a 'I clicked on a service block' to launch the inspector? [18:42] hatch: kadams54 so it's more done off of the 'how' it was accessed vs tracking 'have you been seen before' kind of thing? [18:42] rick_h_: yep there is [18:43] that's a good idea [18:43] reaaal easy to implement heh [18:43] tracking a flag on a model makes me :( at first glance [18:43] heh cool [18:45] rick_h_: i'm in the standup room. [18:45] jcsackett: joining [19:04] rick_h_: hey, if a bundle doesn't have specific versioned charm will the store injest it? [19:04] ingest* [19:04] in a personal branch [19:04] marcoceppi: yes, I think it should [19:04] cool [19:04] marcoceppi: if proof doens't show an E then it should be good [19:05] rick_h_: awesome,t hanks [19:15] oo new humble bundle is a star trek comic book one https://www.humblebundle.com/books === fabrice|dinner is now known as fabrice [19:48] * rick_h_ runs away for the day. I'll be back online later at coffee house time. [19:48] marcoceppi: new review queue looks awesome - but why such a funky url? Shoudln't it be on jujucharms or juju.u.com? [19:49] cya rick_h_ [20:03] jujugui anyone know how to force destroy a machine using local? [20:06] hatch: it's not prime time yet [20:06] hatch: we'll have it so the current url maps here, until then it's a "Google beta" [20:07] ahhh haha :) [20:07] I have a problem with my ghost charm on jujucharms.com but I can look into that later I suppose [20:07] it shows ghost-0 even though it definitely shoudln't be 0 [20:10] blarg I can't reliably reproduce this issue [20:25] laptop sounds like it's going to take off.....realize I have 15 lxc instances running [20:25] oops....:) [20:25] MOAR CONTAINERS!!! [20:26] it sounds light until I remember that is 15 juju's running. No shared memory :( [20:31] haha [21:05] intermittent race condition errors are da-best-yo [21:27] jujugui https://github.com/blog/1884-introducing-split-diffs let there be light [21:27] Nice [21:27] rick_h_: welcome to an hour ago https://twitter.com/FromAnEgg/status/507263886165573632 [21:28] pssshhhttt [21:28] doh :P [21:28] lol!! [21:28] hey, I was chopping tomatos for tacos :P [21:28] It's Taco Tuesday! [21:28] On a Wednesday. [21:28] woot! [21:28] oh this is so nice [21:31] yeah what took them so long hah [21:31] no kidding, works much smoother than the extension as well [21:31] the comment buttons always got messed up, I gave up on the chrome extension [21:32] the ff extension just didn't work. [21:38] yeah same [21:48] rick_h_: does charmworld have a landing bot? [21:49] been so long since i've touched it i forgot how charmworlds review/land process looks, and i'm trying to marshal along brad's branch. [21:53] guihelp: ^ [21:53] noooo idea [21:54] suddenly thinking this is a rietveld/lbox show. [21:54] b/c why have two websites to review code on when you can have three? [21:57] lol [23:03] Morning [23:07] morning huwshimi [23:32] huwshimi: morning [23:32] huwshimi: we talked about putting off the size sort for now until we can get constraints in order and better define it [23:33] huwshimi: does that unblock your branch from moving foward and landing? [23:34] rick_h_: Ah yes, that's great [23:34] wow I just got an ec2 capacity not available warning when trying to bootstrap [23:34] hatch: whoops [23:34] I'm doing a dry run of getting my blog transfered to ghost [23:34]