[12:30] <benji> BradCrittenden: you can't seem to settle on a name here lately
[12:30] <benji> I have a small review up that could use your attention: https://code.launchpad.net/~benji/charmworld/migration-018-delete-bundles/+merge/181807
[12:30] <BradCrittenden> benji: yeah, i got the dropouts.
[12:31] <benji> ooh, I hear that can be fatal
[12:31] <BradCrittenden> the nick retention period is much longer than the time it takes me to reconnect so it won't let me have 'bac'
=== BradCrittenden is now known as bac
=== bac is now known as InigoMontoya
[12:32]  * InigoMontoya prepare to die
[12:38] <benji> InigoMontoya: you can /release the nick by talking to NickServ and he'll let you have it back
[12:40] <InigoMontoya> benji: no, it isn't a problem, i can usually get it back quickly.  but i have to notice the problem after my client reconnects
[12:41] <benji> why does your client choose the wrong nick?
[12:41] <InigoMontoya> benji: b/c when it reconnects freenode has not yet released 'bac' and i guess i have the longer one as my alternate.
[12:42] <benji> ah; I have some purge-all-past-incarnations commands that my client runs when I connect.  That helps a bit with that.
[12:42] <InigoMontoya> benji: moving on to other topics:  i'm about ready to break out 'rev' as a separate field in the mongo doc.  it seems crazy to go to all of the trouble i'm having just for this issue.
[12:43] <InigoMontoya> benji: it can still be part of the _id as needed
[12:43] <InigoMontoya> benji: reality-based objections?
[12:43] <benji> makes sense; will you also have the search_id as part of the document, so you can search on it?
[12:44] <benji> no, but Falcor isn't a fan of the idea
[12:44] <benji> ah, who am I kidding, Falcor loves everyone
[12:44] <InigoMontoya> unsure about search_id
[12:46] <benji> I figured that since you want to search on everything but the revision, the search ID would be the way to go (since that's what it is)
[13:02]  * sinzui sets charmworld to benji's 264
[13:02] <sinzui> 364 I mean
[13:02] <jcsackett> rick_h: if you can look at https://codereview.appspot.com/12935046/ again i updated it yesterday.
[13:04] <rick_h> jcsackett: cool looking
[13:04] <rick_h> jcsackett: ah, I saw jeff gave you a lgtm so I didn't go back to it
[13:04] <jcsackett> rick_h: it's LGTM with your proposed changes; figured i would make sure you were happy with those changes.
[13:05] <jcsackett> if you want to hand wave it i'm happy to go ahead and land it. :-P
[13:05] <rick_h> ok, looking now
[13:07] <sinzui> benji, I see from the log the migration was run. I still see the wiki bundle. This might be a timing issue because ingest starts *before* the website is brought back up
[13:08] <rick_h> jcsackett: replied. 
[13:08] <jcsackett> rick_h: dig, thanks.
[13:10] <jcsackett> jujugui: i need two reviews on https://codereview.appspot.com/12741050 and someone with IE to QA. it's an easy one--just a bunch of deletions.
[13:11] <benji> sinzui: I would suspect timing.  The migration is simple and its tests seem to be representative.  If the bad bundle doesn't cause any errors, I would suspect re-ingestion.
[13:12] <sinzui> benji, The ES data is different. The search that worked yesterday doesn't work. I think all is well.
[13:12] <benji> cool!
[13:12] <sinzui> benji, are bundles ingested first?
[13:12] <benji> thanks for working on it
[13:12] <benji> I don't know the order off the top of my head.
[13:12]  * benji looks
[13:13] <sinzui> I think they are, meaning the first bundles will always be place before the website restarts
[13:13] <benji> sinzui: it depends on the hash order of a dictionary, so it should be consistent, but is unspecified
[13:27] <sinzui> benji, bac: do either of you have time to review  https://code.launchpad.net/~sinzui/charmworld/provide-type-from-api-search
[13:27] <frankban> bac, benji: when you have time, could you please review https://codereview.appspot.com/12802045 ?
[13:27] <benji> sinzui: sure
[13:27] <benji> frankban: sure
[13:27] <InigoMontoya> frankban: sure
=== InigoMontoya is now known as bac
[13:28] <frankban> thank you both
[14:03] <rick_h> kind of short notice http://www.yuiblog.com/blog/2013/08/23/save-the-date-yuiconf-nov-6-7
[14:03] <rick_h> hatch:  ^
[14:04] <rick_h> hatch: Makyo updated the branch from yesterday with the bi-directional go constraint conversersion, refactoring, added the sandbox tests/adjustments. https://codereview.appspot.com/13084045
[14:05] <rick_h> hatch: Makyo appreciate a second look though I know I got LGTM yesterday. Feel like a lot's changed, but part of that is in my head
[14:13] <Makyo> rick_h, on it
[14:15] <jcsackett> jujugui: can i get two reviews on https://codereview.appspot.com/12741050, please?
[14:15] <rick_h> jcsackett: will look in a sec
[14:15] <jcsackett> rick_h: thanks.
[14:16] <Makyo> jcsackett, on it.
[14:16] <jcsackett> Makyo: thanks!
[14:20] <sinzui> jcsackett, admin thinks you are on holiday today. Did you forget?
[14:23] <jcsackett> sinzui: it's a half day, PM.
[14:23] <jcsackett> leaving at noon.
[14:23] <sinzui> jcsackett, sorry, I thought you had extended it to the whole day.
[14:24] <sinzui> I think I am the only member of Orange working on Monday.
[14:28] <sinzui> benji, about the access to _representation. I too was hoping that we would have solved this by now for bundles and charms. maybe both classes should have a property that returns dict(self._representation)
[14:31] <benji> sinzui: that would be fine with me; I do worry a little about non-canonical key/values sneaking in, plus it would be nice to have the properies get a chance to return things.  How about returning dict((key, getattr(self, key)) for key in self._COMMON_REPRESENTATION)
[14:34] <rick_h> Makyo: did you do the IE QA on jcsackett's branch?
[14:35] <sinzui> benji, yes, that is better. Maybe we want a guard in the class that ensures unwanted keys are always rejected. __init__ looks flawed. if it was ensured a sane dict, calling @representation or dict(Bundle(data)) could be trusted
[14:36] <benji> sinzui: yep, I like putting the gate earlier too (dict(Bundle(data)) can actually be trusted now because it does its own filtering, but I get your point)
[14:37] <sinzui> benji, okay. I will report a bug for this because I think we want to fix this bad pattern for charms and bundles.
[14:37] <benji> sounds good
[14:40] <Makyo> rick_h, ah, will do that now.
[14:40] <rick_h> Makyo: that's ok, was wondering. My lbox submit finished so I can pull it into my colo now
[14:40] <rick_h> I'll poke at it
[14:41] <Makyo> rick_h, oh, alright.
[14:42] <adeuring> bac, sinzui: could you trying the branch: lp:~adeuring/charmworld/1206659-spurious-errors ? it should fix a number of spurious failures, even some in tests that were not disabled in r362, but I'd like some independent test runs before I claim that everything is fixed...
[14:42] <bac> adeuring: sure!
[14:42] <sinzui> thank you adeuring
[14:45] <bac> adeuring: how long does 'make test' take to run on your slow and fast machines?
[14:45] <Makyo> luca, ping
[14:45] <luca> Makyo: heya
[14:47] <Makyo> luca, the upgrade service ux appears in two different places in the mockup.  I like the second one better - after all of the unit management stuff - because this is by service, not by units, and having it mixed in confused even me for a bit.  Can I go with that one?
[14:47] <Makyo> luca, on https://www.dropbox.com/s/d6sc200adk2dszs/juju-gui-2-inspector-09.jpg
[14:48] <luca> Makyo: they are the same but different :D
[14:48] <luca> Makyo: There is 2 use cases going on here
[14:48] <luca> Makyo: #1 I need to upgrade my servicer
[14:48] <luca> Makyo: #2 I need to revert my service
[14:49] <Makyo> luca, Why is it mixed in with units?
[14:49] <luca> Makyo: When there is a new upgrade that the user hasn't seen yet, the "A new upgrade is available" populates near the top
[14:49] <luca> Makyo: there isn't really a "mixed in with units" thing, they are just notifications, it's all about hierarchy
[14:50] <Makyo> luca, I keep getting wireframes with no explanation and being told to implement.  I'd appreciate a call.
[14:50] <Makyo> jujugui call in 10 kanban now.
[14:50] <luca> Makyo: Ah, thats fine. We actually worked with gary on this and most of this way his idea, I would of thought he would of briefed you guys on it before delegating it out.
[14:51] <Makyo> luca, nope.
[14:51] <luca> Makyo: right, when are you available?
[14:51] <Makyo> luca, now for 9 minutes, and in an hour and nine minutes for several hours.
[14:51] <adeuring> bac: the slow one needs ca 100 seconds (...and I just noticed another test failure...)
[14:51] <bac> adeuring: i'm running the tests but they are taking forever to run
[14:51] <adeuring> ..and the fast machine now show a ton of errors even for trunk...
[14:52] <bac> adeuring: in past 'make test' took about 74 seconds for me.  this one is taking minutes
[14:53] <adeuring> bac: interesting. I changed a status check when a temporary index is created for a test. Could be related.
[14:55] <bac> adeuring: still on the first line of dots of test output
[14:55] <adeuring> bac: Then just abort it...
[14:55] <bac> adeuring: even if all tests pass, this is too painful
[14:55] <adeuring> right
[14:59] <Makyo> jujugui call in 1
[15:06] <bac> adeuring: try scripts/reset-db?
[15:06] <bac> adeuring: in a bind, i've rm /var/lib/elasticsearch too
[15:07] <adeuring> bac:  yes
[15:07] <adeuring> i tried both, but i did not restart mongodb, as suggested by sinzui
[15:19] <Makyo> rick_h, constraints are passed from pyjuju in the get_service call, and are hooked up, at least in the inspector.
[15:19] <Makyo> rick_h, will check go too.
[15:19] <rick_h> Makyo: k, cool. Yea I figure pyjuju worked and maybe we never got around to checking/working on -core?
[15:20] <Makyo> rick_h, yeah, will do that now.
[15:25] <bac> sinzui: you said "it is not in saucy".  were you referring to pyjuju or core?  that is, what is in saucy?
[15:26] <sinzui> pyjuju is not in saucy
[15:27] <rick_h> sinzui: ah, that makes sense
[15:27] <rick_h> sinzui: I heard it the other way as well
[15:27] <sinzui> sorry for speaking in curtisese
[15:32] <hatch> rick_h: I'm going to revert the inspector and then I can help you out
[15:33] <rick_h> hatch: k, all good. 
[15:34] <Makyo> Bleh, debug-log no longer uses newlines, nearly impossible o read.
[15:34] <rick_h> joy
[15:35] <hatch> matt I crested a card in urgent and put our heads on it for the IE10 QA
[15:36] <Makyo> hatch, Cool, thanks/
[15:37] <hatch> crested a card
[15:37] <hatch> hmm
[15:37] <hatch> lol
[15:39] <Makyo> rick_h, I am getting constraints from core, too, but they're showing up strangely.  It looks like core responds only in MB, but GUI expects GB for memory, so it says I created a machine with 2048GB of memory.  I hope that's not the case :)
[15:39] <rick_h> Makyo: hah, ok. Good to know. Maybe that follow up card isn't much work then. 
[15:39] <rick_h> Makyo: curious to trace how it was getting the data format and fitting it to the UX
[15:40] <hatch> 2048GB of ram....that must be rick_h's new desktop
[15:40] <rick_h> hah, I'm about 2012 short
[15:40] <hatch> lol
[15:41] <rick_h> err, 2016 that is. /me can't do match on fridays
[15:41] <Makyo> rick_h, It looks like it's just populated in the service model's attrs and bound in the inspector from there.
[15:41] <rick_h> Makyo: cool
[15:41] <rick_h> Makyo: yea, I saw some stuff in the utils that generates titles and such for the UX so maybe it's doing it there. 
[15:42] <Makyo> luca, ping; I'm free if you've got some time before your end of day.
[15:43] <luca> Makyo: ok, I'm in a meeting with Mark S at the moment but I'll join guichat when I'm out.
[15:43] <Makyo> luca, alright, thanks.
[15:48] <benji> frankban: I finally finished looking at your branch, it looks good
[15:50] <frankban> benji: great, thanks
[16:06] <luca> Makyo: I'm on GUI chat
[16:06] <Makyo> bcsaller, in guichat if you want to join
[16:18] <rick_h> Makyo: after your call, was that -core constraint working done via the gui? e.g. you deployed and set a constraint from the gui and then when you opened it back up it was loaded ok, just off as far as units?
[16:19] <Makyo> rick_h, deployed from command line in a real env.  `juju deploy --constraints mem=2G cs:precise/mysql`
[16:19] <rick_h> Makyo: ok, I'd be curious then if settnig via the gui does work since that's where I was looking for us to translate the names of the constraints to the Go format. 
[16:24] <rick_h> hatch: running out to grab some food. Looks like my last branch had the wrong 'structure' for constraints and so needing to clean that back up. Latest work is in lp:~rharding/juju-gui/ghost-constraints-1125352 if you want to poke and if you wanted to pair on it in a bit. 
[16:24] <hatch> rick_h: ok sure - I have a few emails to write then I'll be on it
[16:25] <rick_h> hatch: np, biab
[16:45] <hatch> hmm
[16:45] <hatch> fresh trunk test failures....
[16:52] <hatch> I'm always confused how this happens
[16:56] <hatch> oh it did fail in CI too
[16:56] <hatch> it was just masked by the selenium failures
[16:56] <rick_h> hatch: details on what I broke?
[16:56] <bac> frankban: review done
[16:57] <hatch> rick_h: I think it was a bad merge
[16:57] <rick_h> hatch: hmm, yea that sucks. I mean it has to merge/pass tests to land so confused
[16:57] <hatch> rick_h:  https://gist.github.com/hatched/13dd112c33c1263476f4
[16:57] <frankban> bac: thanks!
[16:57] <hatch> oh woops
[16:57] <hatch> heh
[16:57] <hatch> the 'expected' is the Constraints object
[16:58] <hatch> ^ rick_h
[16:58] <rick_h> hatch: yea, looking
[16:58] <rick_h> hmm, those are tests I changed and such but not seeing the /actual/expected 
[16:59] <rick_h> hatch: but I can pull down trunk again and see if I can replicate it locally. Sec
[17:01] <hatch> thanks
[17:01] <rick_h> hatch: ok, I have the same error here. Will hack a branch to see what's up/fix it.
[17:02]  * rick_h wonders how the $@#$@# it landed then. 
[17:02] <hatch> yeah right!?!?
[17:02] <hatch> maybe you had an old test server running :D
[17:02] <hatch> that caught bcsaller once hehe
[17:02] <rick_h> oh, and the lbox hit that vs its own?
[17:02] <hatch> yup
[17:03] <rick_h> hmm, guess that's possible. I was running tests. 
[17:07] <rick_h> hatch: cool, easy fixes. Must have done that I guess. Sorry about that :/
[17:07] <hatch> yeah....you'll pay for this....
[17:08] <hatch> with your cpu.....mohohahahahahaha
[17:08] <hatch> I figure that would be from Futurama
[17:08] <rick_h> haven't I already suffered enough on this card? plus more lboxing...the punishment!
[17:08] <hatch> pssht lboxing for you is what....20s? :P
[17:08] <rick_h> no, stupid bzr/launchpad/branching :/
[17:09] <hatch> ahhh right right
[17:12] <hatch> rick_h: gave you an lgtm
[17:12] <rick_h> hatch: cool thanks. 
[17:17] <rick_h> hatch: ok, fix heading down for that. 
[17:17] <hatch> great - once it lands I can then revert the flag branch
[17:17] <rick_h> it's in trunk at least. bzr pull will have it and you can start
[17:18] <hatch> cool proposing
[17:21] <hatch> jujugui fyi I'm putting bugs which will block the release in maintenance/urgent
[17:21] <rick_h> hatch: k
[17:23] <hatch> jujugui review for reverting the inspector as the default https://codereview.appspot.com/12739049/
[17:25] <hatch> Makyo: I can't find any IE10 specific bugs \o/ lemme know what your result is whenever you get a chance
[17:26] <rick_h> hatch:  looking
[17:27] <hatch> landing thanks for the reviews Makyo rick_h
[17:38] <Makyo> My IE is so small :S  I should see if I can get VB to pretend like I have a bigger monitor.  The unit details view goes off the edge of the screen.
[17:42] <Makyo> Happens in all browsers, ditto with fullscreen.  I think I  just have it smaller than our minimum size is all
[17:44] <Makyo> hatch, maybe worth a card, but I don't think I'd consider it a blocker.  Looks fine once I get above something like 1024x768 :P
[17:46] <hatch> haha that's pretty small
=== rogpeppe3 is now known as rogpeppe
[17:49] <Makyo> hatch, yeah. vbox just picked up a small default.
[17:50] <Makyo> hatch, also, relation labels are too high.  Also small.  Probably defaulting to a baseline at the bottom rather than the middle.
[17:50] <Makyo> hatch, no blockers, though.  Everything looks/works fine otherwise.
[17:59] <hatch> awesome! :D
[17:59] <hatch> thanks for that
[18:00] <rick_h> man, almost have my own charmworld/juju-gui running in lxc containers but can't configure the juju-gui to set the charmworld url away from manage.jujucharms.com
[18:01] <hatch> rick_h: sounds like a bug to me :)
[18:03] <rick_h> hatch: trying to set via cli and see if it works
[18:04] <rick_h> hatch: yea, worked via cli. hmmm, need a release to check if it works via the inspecgtor
[18:08] <rick_h> http://uploads.mitechie.com/lp/lxc-jujugui.png so that's all in lxc containers. Charmworld hadn't finished ingesting and such. However cool to run it all locally. 
[18:08] <rick_h> pretty quick overall
[18:08] <rick_h> so thanks for the charm-school jcastro ^ 
[18:10] <hatch> that is awesome :) I need to do that at some point
[18:11] <rick_h> 20GB of ram left, time to try to run 100 juju-guis
[18:11] <hatch> very odd issue with the CI failures this time
[18:11] <hatch> I guess I'll retrigger it and see what happens
[18:11] <hatch> rick_h: so where are we with the ghost constraints stuff? Anything i can help with?
[18:12] <rick_h> hatch: sorry, took a break to watch the charm school on lxc stuff to test things coming up. 
[18:12] <rick_h> hatch: so we're doing ok. Fixing the constraints object conversion to work
[18:12] <rick_h> python works, go api fails. 
[18:13] <hatch> who needs Go anyways
[18:14] <rick_h> heh, my branch is going to leave the api set to go in the config-debug per our discussion today
[18:15] <hatch> I think I missed that discussion
[18:15] <hatch> guichat to bring me up to speed?
[18:15] <rick_h> sure
[18:32] <hatch> awesome HTC is going to fix the mrs phone - now I can go get a new phone haha
[18:42] <hatch> canceled CI trying again...
[18:43] <rick_h> hatch: ok, might need a chat after all. Data seems to go in, won't come back out
[18:45] <hatch> rick_h: ok in a few minutes just eating a sandwitch :)
[18:45] <rick_h> hatch: rgr
[18:51] <hatch> arg I don't know what's up with this CI
[18:56] <hatch> rick_h: ok sandwitch done ....guichat?
[18:57] <rick_h> hatch: rg
[18:57] <rick_h> rg
[18:57] <rick_h> damn rgr
[19:41] <bac> benji, sinzui: in our google doc, we agreed the api endpoint should be plural "bundles" but it is still "bundle".  any objections to me fixing it?
[19:41] <benji> bac: are we going to change "charm" to "charms"?
[19:42] <benji> wait, there already is a "charms"
[19:42] <benji> bac: we changed it the other way, API2 had "charms" but API3 has "charm"
[19:42] <sinzui> bac, charms/ is a searchable collection, charm/ is an individual charm
[19:43] <sinzui> bac /search is a collection of all bundles and charms and it replaces charms/
[19:43] <bac> sinzui, benji: looky here: https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit#heading=h.u3246vho9aig
[19:43] <sinzui> bundle/ would provide a single bundle I think
[19:43] <bac> fourth bullet point
[19:43] <bac> http://staging.jujucharms.com/api/3/bundles/~abentley/wiki-bundle/1/wiki
[19:44] <sinzui> bac, I know.bundles/ is fine because we moved charms/ to search/
[19:44] <benji> bac: I don't really care much one way or the other, just making the current state known
[19:45] <sinzui> bac, benji. I don't have an opinion about the plural of bundle(s)/, but I want it to be consistent with charm/ which is what we have now
[19:46] <benji> +1
[19:46] <sinzui> we can rename charm to charms/ in api3
[19:46] <bac> sinzui: well it is easier to fix the google doc than the code
[19:46]  * sinzui is dizzy from seeing all his work not come to fruition today
[19:47] <bac> actually, no because we have:
[19:47] <bac> http://manage.jujucharms.com/~sinzui/bundles/mysql/5/tiny/json
[19:47] <bac> http://manage.jujucharms.com/bundles/mysql/tiny/json
[19:48] <bac> so, in the branch i'm about to propose they are all going to be 'bundles'
[19:48] <bac> if we want to change them to 'bundle' we can do that, after updating the doc
[19:48] <bac> i gotta land this thing!
[19:49] <sinzui> bac, sure. We will revisit all the URLs in SEO soon anyway
[20:00] <sinzui> bac, I can review your branch if you want https://code.launchpad.net/~bac/charmworld/official-bundle-json/+merge/181909
[20:00]  * sinzui needs a break from failing to show interesting bundles
[20:00] <bac> sinzui: it has conflicts.  i'll let you know when it is fixed -- thanks!
[20:26] <bac> sinzui: conflicts fixed
[20:26] <bac> sinzui: sorry the diff is so long
[20:28] <sinzui> bac: np
[20:28] <sinzui> bac, can you review https://code.launchpad.net/~sinzui/charmworld/api3-interesting/+merge/181910 ? It is very short because I got lost
[20:28] <bac> sure
[21:17] <sinzui> bac, I replied with 2 questions
[21:20] <bac> sinzui: ok
[21:28] <bac> sinzui: thanks for the mongo sort reminder.  i'd tried that yesterday, before i made basket_revision a field.  i'll make that change now.
[21:29] <bac> sinzui: as to the other, yes basket_with_revision is a better name
[21:29] <sinzui> bac okay. I was only asking questions. Make changes as you like; r=me
[21:56] <bac> sinzui: would you update https://docs.google.com/a/canonical.com/document/d/17bgbReU6JJMoUHSJeo8egG5zoSM0fpPIs7U8F1-Piyk/edit# with check marks?
[21:56] <sinzui> bac, The 3 interesting parts aren't done-done
[21:57] <sinzui> I did verify routing with versions is good
[21:57] <bac> sinzui: 4b and 4c aren't done?
[21:58] <sinzui> bac, api supports them, but until we change ingest and views to collect the data, no one will see which is new or popular
[21:59] <sinzui> well...considering how new bundles are, we might not ever see popular bundles
[22:01] <bac> good point sinzui.
[22:01]  * bac dog walk
[22:17] <sinzui> bac, I deployed your changes to staging. They work for the most part, but I think there is something amiss with the basket-name: http://staging.jujucharms.com/~abentley/bundles/wiki-bundle/1/wiki/json is not found  and a search for abentley finds a bundle without a basket.
[22:21] <sinzui> bac, I need to make dinner so will sign off. I think we need to update ingest or the model to handle the / in the basket. I see this in the DB: { "_id" : "~abentley/wiki-bundle/1/wiki", "owner" : "abentley", "basket" : "wiki-bundle/1"}
[22:22] <sinzui> well, before I go I will delete the bundle from staging so that we can check with a fresh ingest.
[22:23] <hatch> man there has to be something wrong with canonistack
[22:25] <sinzui> hatch, how do you mean
[22:25] <hatch> the ci just hangs after loading in the selenium deps
[22:25] <hatch> and I can't find anything wrong with it
[22:26] <hatch> it's like it can't create a new instance or something
[22:27] <sinzui> hatch, are the deps enormous?
[22:27] <hatch> I don't think so it always gets to "FInished processing dependencies for selenium==2.33.0"
[22:27] <hatch> then sits there for 45mins until it times out
[22:33] <sinzui> hatch, I wonder if there is a network issue. I thought this might be an issue with the charm payload. which is bug 1156649
[22:33] <_mup_> Bug #1156649: pyJu fails to deploy/upgrade charm with 32MB payload <juju:New> <https://launchpad.net/bugs/1156649>
[22:34] <hatch> hmm nope it's not even getting that far
[22:34] <hatch> I think I'll bench this and make a card
[22:34] <hatch> start on it again on monday
[22:34] <sinzui> hatch, I think you are getting much farther since you have an instance doing an install
[22:34] <sinzui> have a nice weekend
[22:35] <hatch> you too!
[22:38] <sinzui> bac: I have good news and bad news. Since I did not go away as I claimed I was, I was here fir the reingest of the bundle. It works! this means we need a migration to purge all bundles before your changes are activated. Oh, but since I happen to know benji landed just such a migration 9 hours ago, we can just pretend you have. I am confident that no bundles will be in the db when we restart production.
[22:39] <sinzui> bac have a nice weekend.
[22:41]  * benji is glad to be part of the good news for once.
[22:51]  * bac missed the bad news
[22:52] <bac> it sounded like good news & good news