[16:45] <rick_h_> cory_fu: ty for the bundle v4 support MP's. I've asked Makyo to peek and help make sure everything looks cool and we've no suggestions from our end.
[16:46] <cory_fu> Awesome, thanks.  We need these changes to get the big data bundles passing the test runner.  I tried to make the minimal changes to include support, so definitely LMK if it could be addressed better, though I would like to see a fix out as soon as possible so we can see our bundles passing.  :)
[16:48] <rick_h_> cory_fu: understand, Makyo will look today and so can help provide feedback pretty quickly
[16:48] <cory_fu> Thanks
[16:51] <Makyo> cory_fu: +1
[16:51] <cory_fu> Excellent.  Thanks
[16:52] <cory_fu> I do wish there were a better way to distinguish the bundle formats.  Adding a "version" or "format_version" or such field would be really n ice
[16:53] <Makyo> cory_fu: agreed :/ We went through similar hoops in bundlelib.
[16:54] <cory_fu> Adding a top-level key that is required for v4+ and defaults to v3 seems like it would be reasonable to me, but that's just off the top of my head
[16:55] <rick_h_> cory_fu: we thought about it, the issue is that we're asking the user to tell us and it's a chance for a user to get it wrong
[16:55] <rick_h_> cory_fu: so it's awesome from a lib developer standpoint, but a pita for a bundle writer/user standpoint as it's one more thing to break
[16:56] <cory_fu> There is that.
=== urulama is now known as urulama__
[16:56] <rick_h_> cory_fu: so we take the burden in the hopes the devs appreciate it and buy us beers one day :)
[16:58] <cory_fu> rick_h_: OTOH, there are clearly constraints that the user already has to conform, and we provide tools to help them do so (proof).  Allowing the user to be explicit about the version they *intend* seems like it would actually lead to fewer confusing errors.
[16:59] <cory_fu> I guess the current heuristics are fairly reliable due to the drastic change in the format, though
[17:00] <rick_h_> cory_fu: yea, I can be convinced we're wrong for sure. Honestly, we've not had the uptake in folks using it since we released it because they didn't "HAVE TO" so we don't have good data either way
[17:00] <rick_h_> cory_fu: but just fyi'ing on the picture there as it was thought about for sure
[17:01] <cory_fu> Well, I'm sure the lack of support in the rest of the tooling (proof, deployer, bundletester, etc) didn't help uptake, and all of that is now changing
[17:01] <rick_h_> cory_fu: <34
[17:01] <rick_h_> err <3
[17:01] <cory_fu> heh
[17:01] <cory_fu> I read that as "less than rule 34" and was a little concerned.
[17:02] <rick_h_> my typing is horrible today, must have gotten my fingers more bit up fishing than I thought this weekend :P
[17:02] <cory_fu> Ouch
[17:03] <rick_h_> those bass tear up your thumbs when you lip them hah!
[17:03] <cory_fu> ha, I'm sure
[18:54] <sinzui> hi bac, jcsackett, Do either of you have time to review https://code.launchpad.net/~sinzui/juju-quickstart/all-regions/+merge/268961
[19:23] <rick_h_> Makyo: ^ ?
[19:23] <Makyo> I'll take a look rick_h_ sinzui
[19:23] <rick_h_> Makyo: ty much!
[19:24] <Makyo> I'm glad we've finally settled where Amsterdam is.
[19:25] <Makyo> +1
[19:28] <rick_h_> Makyo: can you land that if that's cool please?
[19:29] <Makyo> rick_h_: sure
[19:31] <Makyo> rick_h_: Embarrassing, but I only ever used lbox to merge code on launchpad.  Do I need to do anything other than mark it as merged?
[19:32] <rick_h_> Makyo: you have to run the lbox submit thing. 
[19:32] <rick_h_> Makyo: basically if you can run tests then you bzr branch, merge it into trunk, push to  trunk. 
[19:32] <Makyo> rick_h_: ack. Will take a bit to get that updated.
[19:32] <rick_h_> Makyo: understand
[20:12] <Makyo> rick_h_: sinzui I did the thing! \o/  
[20:12] <Makyo> Been forever since I worked with bzr, sorry for the delay.
[20:14] <sinzui> thank you Makyo