=== flaviamissi_ is now known as flaviamissi [08:04] fwereade: mornin' [08:04] wrtp, heyhey [08:13] fwereade: my ping last night BTW was to let you know that i'd found an old branch that actually made some of the juju commands work, in case you were about to work on something similar. [08:14] fwereade: it's funny though, i dusted off the branch, split off a part of it that was logically separate and proposed that, then proposed the original again, and only *then* did i discover i'd proposed it before and even had a LGTM! [08:15] wrtp, yeah, it was nagging at my mind, I *thought* you'd done something like that :) [08:16] fwereade: yeah, exactly. i looked at cmd/bootstrap and thought "i thought this was working now", then i found the branch and thought i'd never got around to proposing it. [08:16] fwereade: there was quite a bit of code that i'd totally forgotten about [08:17] wrtp, heh, ouch :) [08:18] fwereade: it's fine. nobody's written anything similar in parallel, and the tests are *almost* passing. [08:18] fwereade: it's quite nice actually. [08:20] wrtp, awesome :) [08:21] wrtp, the Init change will hit one of us soon but it shouldn't be a bother [08:21] wrtp, oo, cath has made breakfast, bbs :) [08:21] fwereade: is there another Init change in the offing? [08:21] fwereade: enjoy! [08:21] hey Daviey [08:30] wrtp, oh, yeah, Init went in already; sorry, confused :) [08:30] wrtp, (mmm, maltese bread :)) [08:31] * wrtp has no idea what maltese bread might be like, but thinks he should have some breakfast because his mouth is watering. [08:32] (mmm, Sainsbury's muesli :-)) [08:32] TheMue: hiya [08:33] wrtp: moin, just came back from workout [08:34] wrtp: … and a discussion with my daughter that a fresh setup of a computer keeping software and data is more than a five minute job [08:34] * TheMue laughs [08:38] TheMue: what, you mean you can't just do "juju add-unit ms-windows --constraint machine=daughters-computer ? :-) [08:40] fwereade: what *is* maltese bread like, BTW? [08:40] wrtp: Hehe, no. And even no "osx" (she's got an Apple). OK, installing the OS is done quickly, but a backup of her data as reinstallation of her software later. [08:41] Btw, anyone already upgraded to 12.04? [08:42] wrtp, crusty on the outside, awesomely soft and springy on the inside, nice taste that I don't really have the vocabulary to describe; works really *really* well with tomatoes, capers, maybe basil, little bit of oil [08:42] * fwereade is hungry again [08:42] TheMue: not I [08:43] TheMue, yeah, haven't got around to it yet [08:43] fwereade: white or brown? [08:43] wrtp, white [08:44] wrtp, fwereade: Will also wait a few days until upgrade. [08:45] fwereade: Hey, I'm trying to loose some weight. Please don't write about delicous food here. ;) [08:46] * fwereade resists the urge [08:47] * TheMue once again listens to Porcupine Tree and is happy about such a great music [09:17] wrtp, btw, you remember we had a discussion about cmd/jujuc/server and tomb the other day [09:17] fwereade: i do [09:18] fwereade: i suggested not using tomb in that case if i remember rightly [09:18] wrtp, I must say I keep wanting to use tomb when I look at it -- for example, as it is I think it will be tricky to implement both Close and Wait nicely [09:19] fwereade: does it need a Wait? [09:19] wrtp, perhaps not yet; but without one, error discovery is deferred until you want to close the server anyway [09:19] wrtp, and that feels like it could be a problem [09:20] fwereade: i see [09:20] fwereade: depends whether something might want to wait for an error and start a new server or something [09:21] fwereade: but to be honest, when are you ever going to get an error here? accept is never going to fail in reality. [09:22] wrtp, I don't know... but I'm not very comfortable just dropping errors on the floor like that: just because I can't imagine the error doesn't mean it won't happen ;p [09:23] fwereade: can you paste the code again so i can remember it a bit better? [09:23] wrtp, http://paste.ubuntu.com/947032/ [09:25] fwereade: are you ever going to implement any other methods on Server? (other than Wait) [09:25] fwereade: cos i have a suggeston [09:25] iom [09:25] wrtp, I don;t think so [09:25] ion [09:26] wrtp, go on [09:26] fwereade: why not remove the server type, and replace with a function: RunServer(...) error [09:26] ah, no [09:27] wrtp, I *think* I need both wait and close [09:27] well, why not [09:27] fwereade: when are you going to want to shut down the server? [09:27] fwereade: won't it always run forever? [09:27] wrtp, as part of an orderly shutdown in preparation for a code upgrade, for example [09:28] fwereade: if we're doing that, won't we be exiting the whole program anyway? [09:29] fwereade: alternatively... [09:31] fwereade: don't start the server on NewServer - just return the server object. then implement Server.Run which blocks when called. [09:31] wrtp, ah, that sounds like it could work [09:31] fwereade: similar to rpc.Server.ServeConn [09:32] wrtp, I'll try that, ty :) [09:32] fwereade: np [11:34] fwereade, TheMue: https://codereview.appspot.com/6120052/ [11:34] *click* [11:34] you have reviewed it before, but it has changed a certain amount [12:00] wrtp, I can't decide whether I like the bootstrap Init [12:01] fwereade: you mean that it initialises the Conn rather than just the env name? [12:01] wrtp, it kinda feels as though an error in juju.NewConn would be better reported to the user with os.Exit(1) rather than (2) [12:01] wrtp, which is the observable distinction between Init and Run errors [12:01] fwereade: it means we can uniformly test that all commands open their environment correctly [12:02] fwereade: although perhaps there's another better way of doing that that i haven't thought of [12:03] wrtp, I don't see how that follows -- the code is duplicated in the Inits of Bootstrap and Destroy, so where we happen to test it is a matter of choice [12:04] wrtp, now I think of it, what we did with Log could quite easily work with other chunks of common command functionality [12:04] fwereade: ah, now yer talkin [12:05] wrtp, I think it'd work out really quite nicely :) [12:05] fwereade: consider it done [12:05] wrtp, cool [12:05] wrtp, I'll leave a comment for form's sake, I haven't finished looking through it yet [12:05] fwereade: are the final Log changes submitted yet? [12:06] wrtp, afraid not, you'll have to look at the CL for the latest [12:06] fwereade: k [12:06] wrtp, hoping that this morning's modifications will pass muster :) [12:24] fwereade: i'm not sure that that approach entirely solves the problem. it looks to me like we'll still need to test the environment behaviour of every command. [12:24] fwereade: for instance, here's what bootstrap might look like: http://paste.ubuntu.com/947216/ [12:26] fwereade: although, i suppose that if we test at least one working example, we can infer the fact that the command has the correct c.env.open call, and hence testing the env name after Init is sufficient. [12:26] wrtp, I think that's a good boundary, yeah [12:27] fwereade: yeah, i think i'll do that. [12:29] wrtp, other comments delivered btw [12:30] fwereade: tyvm [12:57] Hello! [12:59] niemeyer: yo! [13:05] niemeyer: moin [13:12] fwereade: PTAL [13:12] niemeyer: https://codereview.appspot.com/6120052 [13:12] niemeyer, heyhey [13:14] fwereade: https://codereview.appspot.com/6115048/ reviewed [13:14] niemeyer, tyvm [13:14] fwereade: My pleasure [13:15] niemeyer, ah, I think I missed the import of what you said before [13:15] wrtp: Ohhh, tasty [13:15] fwereade: You mean re. public/private? [13:15] niemeyer, Help should probably be public if for no other reason than directness of testing [13:15] fwereade: Yeah, it looks like a nice piece for the API [13:16] niemeyer, there's a followup that covers that but it's WIP until the parent pipeline settles down [13:16] fwereade: That's ok [13:16] niemeyer: you reviewed it before some time ago, and i forgot about it, found the old branch, dusted it off, split it, and only when i re-proposed did i find the old thread! [13:16] wrtp: Hah :-) [13:17] wrtp: Nice to see this going along the cool improvements by fwereade in the last few days [13:17] niemeyer, I feel that "ERROR:" beats "error:" in practice merely because it's often followed up with "usage:", etc, and it makes it stand out much better [13:18] wrtp: Should we do a gigantic s/Environ/Env/ replacement? [13:18] fwereade: the Init/Run distinction works well. i don't know quite why we didn't go with that originally. maybe because we didn't think of the trick of passing in FlagSet [13:18] and s/environs/envs/ etc [13:18] niemeyer: i like Environ [13:18] niemeyer: but i'd prefer "environ" as the package name [13:18] wrtp: I see we often pick one or the other arbitrarily [13:18] wrtp, indeed, it would be interesting to go spelunking through its very early history in my copious free time ;) [13:19] fwereade: yeah, there was a long discussion AFAIR [13:19] That's of course not too important, and if there's no agreement let's move on [13:20] niemeyer: i realised that unnecessary plurals don't help anything. hence my "environs->environ" suggestion. [13:20] niemeyer: but i'm much less keen on abbreviations than i used to be :-) [13:21] wrtp: I'd take "env" as a tradeoff ;-) [13:22] niemeyer: i'll think about it [13:23] wrtp: FWIW, we had "environs" to free the "environ" name for variables, if I'm not mistaken [13:23] I may be wrong, though [13:23] niemeyer: maybe. though we usually use "e" or "env" (a good reason not to rename the package, perhaps) [13:24] niemeyer: Just for info, https://codereview.appspot.com/6111053/ has the changes after the review in and https://codereview.appspot.com/6118055/ is a new one I would like to see in trunk before moving the watchers. [13:25] wrtp: Or a good reason to have it as juju/envs [13:25] wrtp: same as strings, bytes, .. [13:25] TheMue: Cool, thanks [13:26] niemeyer: i don't feel like i type it that often, or that it's an eyesore when i do. [13:26] wrtp: "that"? [13:26] niemeyer: although i'm still thinking :-) [13:26] niemeyer: "environ" [13:26] niemeyer: "Environ" [13:26] wrtp: Ah, .. it's more that we can't agree on the proper way to abbreviate it [13:27] wrtp: Not that I dislike it per se [13:27] niemeyer: true. [13:27] wrtp: Your branch has EnvName [13:27] niemeyer: ah! [13:27] niemeyer: now i see where you're coming from! [13:27] wrtp: It's not the only place.. it just reminded me of the issue [13:28] niemeyer: hmm, you're right: http://paste.ubuntu.com/947322/ [13:28] wrtp: I'm pretty sure I had reviewed that branch before, but my comments are not there.. was there a different thread in place already? [13:28] niemeyer: look at the first message in the thread [13:28] niemeyer: i had to make a new CL because i changed the dependency [13:29] OMG [13:29] I can see that :-) [13:29] wrtp: I reminded of it because I still feel the same way about the tests [13:30] niemeyer: all of them? i think there's enough commonality to justify tables, but perhaps only because i anticipate very similar tests for other subcommands. [13:30] wrtp: cmd_test.go [13:31] niemeyer: there are two table-driven tests there. [13:31] wrtp: It feels over the top.. I'm tempted to reduce them to straightforward checks to see how it'd look [13:31] niemeyer: the first one really will be identical for every command that takes a --environment flag [13:31] wrtp: Maybe I'm just missing how complex it is, but the amount of exceptions and reflection on these tests makes me feel like it's being unnaturally forced onto a table [13:32] niemeyer: i don't see any exceptions in the EnvironmentInit tests, or reflection in the Commands tests. [13:34] niemeyer: your argument is stronger for TestCommands, i think [13:34] if t.initErr != "" {; if t.runErr != "" {; com := testInit(c, t.cmd, t.args, t.initErr); etc [13:34] niemeyer: i could easily factor out the command test thing into a function. [13:35] wrtp: This is also extremely simplistic: ops: envOps("peckham", dummy.OpBootstrap), [13:35] niemeyer: say runCommand(c *C, com Command, args ...string) (initErr, runErr error, ops []dummy.Operation) [13:35] wrtp: This only works for cases where it's calling a simple method without any expectations about it [13:36] wrtp: It's mocking on its best.. tying implementation shape to the tests [13:36] niemeyer: that's perhaps true [13:36] niemeyer: i'll try refactoring it. i stick to my guns on TestEnvironmentInit though. [13:37] wrtp: This one is not so bad, but I'd change it to have a list of factories rather than a list of commands [13:37] wrtp: So that the magic copying can go away [13:37] niemeyer: ok [13:41] wrtp: That's the only comment really.. everything else is great [13:41] niemeyer: it doesn't get rid of reflection entirely BTW [13:41] niemeyer: thanks [13:43] niemeyer, wrtp morning [13:43] andrewsmedina: hiya [13:44] wrtp: are you ok? [13:44] andrewsmedina: fine thanks. and you? [13:45] wrtp: when you have time, please take a look https://codereview.appspot.com/6099051/ [13:45] wrtp: im ok [13:45] andrewsmedina: yes i will. thanks for the reminder. [13:48] wrtp: thanks [14:05] andrewsmedina: one question: do you need to be root to run those tests? [14:09] andrewsmedina: also i'm slightly concerned that running the tests might have undesirable side effects (but i'm not familiar with virsh - perhaps there are none) [14:10] wrtp: not. the user that will run the tests need access to libvirt [14:10] andrewsmedina: and side effects? [14:10] wrtp: not [14:11] wrtp: i created and drestoy a dummy net [14:12] andrewsmedina: i don't see anywhere in the tests that the net is destroyed === nijaba is now known as nijaba_tab === nijaba_tab is now known as nijaba [14:14] wrtp: in the other tests I'm using the default libvirt net [14:15] andrewsmedina: sorry, i don't know anything about libvirt. what's the default libvirt net? [14:15] andrewsmedina: is it something the user might be using anyway? [14:16] fwereade: https://codereview.appspot.com/6123049/ done [14:17] niemeyer, tyvm [14:17] wrtp: I'll be more careful in the tests and create a flag for those who have not installed virsh [14:18] wrtp: he may be using the network default but I do not modify it in the tests [14:18] andrewsmedina: isn't starting it a modification? [14:18] niemeyer, nice suggestion, ty [14:19] fwereade: Glad you like it [14:19] wrtp: the start verify if the net is already started [14:19] fwereade: I pondered about the forcing upgrade as well, btw [14:19] andrewsmedina: what if it's not already started? [14:20] fwereade: I didn't bother too much because it's mimicking what's in Py today [14:20] niemeyer, oh, ok [14:20] fwereade: I'm happy to splat the state if we have --force, but I don't think the opposite is sensible [14:21] fwereade: IOW, if somebody does "upgrade --force", and then "upgrade", the second shouldn't drop the --force state [14:21] niemeyer, ah, I thought it... kinda dumb to do so, but not intrinsically *bad* [14:22] niemeyer, fwereade: I found it in the Py code, that a change isn't allowed. [14:22] niemeyer, I don't really feel that it should be an error, even so [14:22] niemeyer, it may silently refuse to downgrade from --force to not [14:22] fwereade: I think it's actually bad because doing an upgrade at all is generally forbidden unless the unit is running fine [14:22] fwereade: The first succeeds because of the --force, and the second succeeds because of the first [14:23] wrtp: a network should be active, inactive or does not exists [14:23] fwereade: So, in a way, the second would only happen at all because there's a --force in place.. [14:23] niemeyer, hmm, ok [14:23] wrtp: if it's active, it's started [14:23] fwereade: That's why, in that situation, I'd rather see "hey, already doing it, hold on" rather than "sure!" [14:23] andrewsmedina: by running this test, the current status is changed. i don't think tests should have side-effects. [14:24] wrtp: in your machine? [14:24] andrewsmedina: that's right [14:24] TheMue: Are you with us [14:24] ? [14:24] TheMue: The summary is: [14:24] andrewsmedina: it's ok if it has side-effects that are cleaned up afterwards [14:24] TheMue: upgrade + upgrade == fine [14:24] TheMue: upgrade + force-upgrade == fine [14:25] wrtp: yes [14:25] TheMue: force-upgrade + force-upgrade == fine [14:25] TheMue: force-upgrade + upgrade == NOT fine [14:25] wrtp: I will use a testdummy net in tests for start method ok? [14:25] andrewsmedina: but anyone should be able to run go test launchpad.net/juju/go/... and be happy that it won't interfere with anything on their machine [14:25] TheMue: Well.. or maybe, fine as well [14:25] fwereade: We could actually make it fine, by saying that the --force continues in place in that situation [14:26] niemeyer: Hmm, sadly don't know enough about the upgrade mechanism in total. [14:26] andrewsmedina: you should make sure to delete the net afterwards too (perhaps by defining TearDownSuite) [14:26] niemeyer, yeah, that seemed nicer to me [14:26] wrtp: you are "+1" for virsh flag or I shoud reuse the lxc flag? [14:26] wrtp: I'm doing it for other tests [14:26] andrewsmedina: i don't understand [14:26] niemeyer, you're not allowed to, er, downgrade your upgrade ;) [14:26] TheMue, fwereade: Ok, so what about this.. let's just move on with what's there given that it mimics what exists today.. we can improve it later [14:26] fwereade: We can then implement that nicer behavior on a follow up [14:27] niemeyer: Sounds ok. [14:27] niemeyer, TheMue: yep, I'm fine with that [14:27] TheMue: Cool [14:28] andrewsmedina: what flag are you referring to? [14:28] * TheMue sadly forgot why he added (TODO) to the comment. [14:28] I'm getting old. [14:28] wrtp: a "--virsh" flag [14:28] ops [14:28] TheMue: So you just need to observe the last of fwereade's point to see how to get to some agreement [14:29] wrtp: a "-virsh" flag [14:29] andrewsmedina: it depends whether you think you can implement the tests without affecting the user's environment [14:30] andrewsmedina: if you don't, i think it would be a good idea to implement some tests that can be run without running virsh, even if they don't verify all the functionality [14:30] wrtp: how I mock the virsh commands? [14:31] andrewsmedina: you could set $PATH [14:31] wrtp: I dont undertand [14:31] andrewsmedina: have a look at state/ssh_test.go [14:31] andrewsmedina: it uses that technique [14:32] wrtp: brb [14:32] andrewsmedina: ok [14:32] fwereade: For the watchers which run concurrently I would like to keep those changes in the background (see the other watchers). Direct write/read tests are already done in state_test.go. [14:37] TheMue, I don't see how it's a benefit to run the test code concurrently when you don't have to [14:39] TheMue, the change goes through ZK just the same either way, and if you skip the concurrency you can eliminate both waiting and the (admittedly unlikely) potential event coalescing [14:40] fwereade: How would you build this as a table driven test? [14:40] wrtp: im back :D [14:41] TheMue, I'm not sure it favours a table-driven style so much as it does a plain old procedural style [14:42] fwereade: niemeyer and wrtp convinced me about the elegant way of doing it table-driven. And I've got to admit, I now like this way. It's clean. [14:42] TheMue, heh, has it changed already? [14:43] TheMue, still don't feel it's a good fit tbh, but perhaps it'll grow on me [14:43] fwereade: What has changed? I had changed other watcher tests to be table-driven today. [14:44] fwereade: All now work the same way, also the new PortsWatcher test. [14:45] TheMue, sorry, I'm just unclear on a largely irrelevant point: whether or not the watcher tests were originally more procedural [14:46] fwereade: I've started them in a more mixed way, asynchronous changes and a procedural testing of the obtained values. [14:47] fwereade: And here it would habe been more simple to move the changes between the tests. [14:47] TheMue, it's the asynchronicity that I feel is the problem anyway, not the table-drivenness [14:48] TheMue, what behaviour does it exercise that a synchronous test wouldn't? [14:48] fwereade: Yes, that's why I asked you if you've got a good idea on integrate the changes int the table too. [14:50] fwereade: I've got no problem in convert it to be synchronous (but in a different branch, all watchers, after moving). But I would like to keep it table-driven. [14:50] TheMue, `func() { unit.OpenPort("tcp", 80)}` ? [14:50] wrtp: I will create the mock for virsh like your ssh tests, ok? [14:50] andrewsmedina: you've got a review [14:51] fwereade: OK, so the table has to be an anonymous struct to contain test func and expected result, but yous, looks ok to me. [14:52] TheMue, cool [14:52] andrewsmedina: i think so. perhaps you might talk to niemeyer some time about this too. [14:52] wrtp: ok [14:52] wrtp: I will improve the tests and talk with you and niemeyer again [14:53] niemeyer: How about you? I would do that change after this watcher and the PortsWatcher are in and then the branch with moving all watchers is in too. [14:59] TheMue: Which change? [15:00] TheMue: The refactoring fwereade suggested? [15:00] niemeyer: I discussed with fwereade to take the concurrent changes out of the tests later. [15:00] niemeyer: Yes. [15:01] TheMue: Yeah, as long as fwereade is happy, I'm happy [15:01] TheMue: and as long as you're happy too, of course [15:01] niemeyer: Fine, and I will keep it as small branches to make you happy. [15:01] TheMue: WOohay small branches! [15:01] :) [15:01] niemeyer, fwereade: Big party! [15:01] ! [15:02] i i i [15:02] ---------- [15:02] *rofl* [15:02] TheMue, I'm happy :) [15:02] | | [15:02] \:-) [15:02] Oh, we get a cake. [15:03] Btw, just had some selfmade chocolate chips by my wife with the coffee. Yummy. [15:09] niemeyer, btw, ERROR/error: thoughts? ERROR stands out much better when the error line is not the only output [15:13] niemeyer: So, submitted, next stop: PortsWatcher. ;) [15:14] TheMue: Was just looking at it, but in a meeting with zaid just now.. will continue after lunch [15:14] fwereade: just a sec and will be with you [15:22] niemeyer: OK, np. [15:30] fwereade: I'd prefer "error: unrecognized flag --foo" than "ERROR: unrecognized flag --foo" [15:31] fwereade: My feeling about it is that it was just a problem detected.. no one is dying :-) [15:31] niemeyer, fair enough, I imagine I'll grow used to it :) [15:31] fwereade: That said, you have a point.. [15:31] fwereade: Something we should do is to reorder the error vs. help [15:31] fwereade: In that one place we print the error & help, error should come last [15:31] fwereade: So it's next to the prompt [15:32] niemeyer, that's no problem... and it will be much clearer in that case anyway [15:32] niemeyer, ok, if I rearrange all that and make it lowercase, good to submit? [15:32] fwereade: In other cases, I suspect that's already happening [15:32] fwereade: I mean, error is already the last thing printed [15:33] fwereade: As long as that's true, I don't see a problem with it being lowercased as it'll be very clear [15:33] fwereade: Yep, +1 [15:34] TheMue: Btw, I just detected a silliness I've suggested that isn't necessary [15:35] TheMue: You know that change, ok := ... if !ok { s.tomb.Kill(nil); return }, that we're using everywhere? [15:35] niemeyer: Yes? [15:35] TheMue: It's not necessary [15:36] TheMue: It's fine to just return in that case [15:36] TheMue: The deferred Done() will make it all work fine [15:36] niemeyer: So check the ok but don't Kill()? OK, I'll change it during refactoring. [15:37] niemeyer: Is it ok when putting it into the watcher movement change? [15:37] niemeyer: So that change would only contain this code change and the moving. [15:39] TheMue: No, please not in the movement change [15:39] TheMue: You can put it in the PortsWatcher, though [15:39] TheMue: As it's just a bunch of one-liner removals, that's fine [15:39] niemeyer: OK, no pro. [15:40] TheMue: If you do that now, please fix the comment of the watcher as well.. it's referring to the copy & pasted watcher [15:40] TheMue: I'll review it right after lunch and hopefully we can already get it in [15:40] niemeyer: fwereade already reviewd it. [15:40] TheMue: Ah, superb [15:40] TheMue: Btw, do you understand why these lines can be removed? [15:40] niemeyer: OK, will change it now and propose it immediately. [15:43] TheMue: Btw, do you understand why these lines can be removed? [15:44] niemeyer: PTAL https://codereview.appspot.com/6120052 [15:45] niemeyer: We don't pass an error to outside, but want to close the tomb and the channel. That's done by defers after the return. [15:46] TheMue: Right, Done() takes care of "killing" the tomb if it's not yet dead [15:46] TheMue: So as long as we're returning from this function, with nil err, just returning is fine [15:47] wrtp: Thanks, I'll have a look right after lunch + TheMue's [15:47] niemeyer: Fine, code reduction at its best. [15:47] TheMue: +1 [16:03] * niemeyer => lunch [16:16] isn't it nice to know that gustavo implies lunch? i'll make sure to have him around as often as possible. [16:20] wrtp: *rofl* took a few moments to get it. [16:20] :) [16:28] hmm, i thought i'd sussed this prerequisite stuff. but despite small diffs [16:28] bzr diff --old lp:~rogpeppe/juju/go-more-commands | wc [16:28] 68 260 2113 [16:28] i guess this: [16:28] https://codereview.appspot.com/6117064 [16:28] s/guess/get [16:30] wrtp: Strange. It claims different changes as yours. Hmm. [16:31] TheMue: yeah. somewhere it's diffing against an unmerged branch [16:31] or something [16:33] wrtp: I still don't understand the prereq stuff. [16:33] TheMue: i thought i did! [16:34] wrtp: As long as the tools are working I'm happy. But in case of a problem I'm lost. [16:42] TheMue: and this is really weird: http://paste.ubuntu.com/947637/ [16:42] if i revert to a revision, isn't the revision-id going to be that revision? [16:42] * wrtp is trying to work out how to diff two revision-ids [16:43] TheMue, wrtp: is it not that lbox requires that changes on the target that have been merged into the proposed branch have *also* been merged into the prereq, even if the prereq has already been merged? [16:43] wrtp: Huh [16:43] fwereade: yes. i did that though, i think [16:43] wrtp, ah ok -- it just looked a bit like it has for me when I've got that wrong [16:43] fwereade: me too. that's why "i thought i understood it!" [16:44] wrtp, haha, sorry :( [16:45] oh, i have uncommitted changes. [16:45] and it wants to remove cmd/juju/destroy.go [16:47] so weird. i could've sworn it passed its test *and* i merged it. [17:00] gn all, take care [17:01] fwereade: gn, take care [17:01] niemeyer, TheMue: https://codereview.appspot.com/6117064 [17:01] all that hassle for about 6 lines of code :-) [17:01] niemeyer, TheMue: ultra-small branch BTW! [17:02] wrtp: *lol* [17:04] wrtp: LGTM [17:05] niemeyer: still waiting for prereq BTW, but i'm sure you know that :-) it turns out that it didn't need to be a prereq, but i didn't want to delete the CL. [17:05] i probably should've [17:06] wrtp: Yeah, I'll just review TheMue's first [17:06] niemeyer: np [17:10] niemeyer: do you know if http.Client.Do is guaranteed to close req.Body ? [17:16] TheMue: Done.. just a couple of trivials [17:16] niemeyer: Fine, thx. [17:16] wrtp: I don't [17:17] niemeyer: np. just wondering about s3 Put. but i don't think it matters actually. [17:26] wrtp: I'd check the implementation [17:26] niemeyer: Do you wonna see the openPortsNode change? Otherwise I submit it. [17:26] TheMue: No, happy to have it submitted, thanks! [17:26] niemeyer: yeah, i did, but it's not greatly obvious [17:28] time to go [17:28] niemeyer, TheMue: g'night. see ya tomorrow. [17:28] wrtp: Yes, good night, I leave too in a few minutes. [17:28]