| wrtp | davecheney: what are you working on currently, BTW? | 04:08 |
|---|---|---|
| fwereade | davecheney, heyhey | 06:33 |
| davecheney | sup | 06:53 |
| fwereade | mramm, what part of the world are you in atm? :) | 08:06 |
| davecheney | i don't think he's real | 08:07 |
| davecheney | his internets might have burped | 08:07 |
| davecheney | it's liek 4am for him | 08:07 |
| niemeyer | Good morning! | 08:19 |
| fwereade | niemeyer, heyhey | 08:21 |
| fwereade | niemeyer, goodness, where are you today? | 08:21 |
| niemeyer | fwereade: Nice summary on the upgrade stuff, cheers | 08:21 |
| fwereade | niemeyer, cool | 08:21 |
| niemeyer | fwereade: Still at home, just alert enough to feel motivated to do something :) | 08:22 |
| fwereade | niemeyer, well, awesome :0 | 08:22 |
| niemeyer | Oh, hey, we've just moved within the company.. | 08:50 |
| * niemeyer gets the boxes | 08:50 | |
| fwereade | niemeyer, sorry, what happened? | 08:50 |
| niemeyer | fwereade: See email from Jane as of 4mins ago | 08:50 |
| fwereade | niemeyer, ah, ok | 08:51 |
| fwereade | niemeyer, well, yay robbie! | 08:53 |
| niemeyer | indeed :) | 08:53 |
| wrtp | fwereade, davecheney, niemeyer: morning! | 09:06 |
| niemeyer | wrtp: Morning! | 09:06 |
| fwereade | wrtp, heyhey | 09:09 |
| wrtp | fwereade: are you sure you were looking at the latest version of https://codereview.appspot.com/6495086/ when you made your most recent comments? | 09:11 |
| fwereade | wrtp, hmm, perhaps not... I just followed the links in your response | 09:11 |
| fwereade | wrtp, aw crap sorry, 2 new revs -- I'll double-cjeck | 09:11 |
| wrtp | fwereade: ah! that would take you to the previous version, i think (unchanged) | 09:11 |
| wrtp | fwereade: no wonder you didn't think it was fixed! | 09:12 |
| fwereade | wrtp, LGTM | 09:13 |
| wrtp | fwereade: phew! | 09:13 |
| fwereade | wrtp, sorry crack :/ | 09:13 |
| wrtp | fwereade: that's fine; very easy to do. | 09:14 |
| fwereade | niemeyer, does anyone actually use upgrade-charm --dry-run? ISTM that it's kinda worthless, because the charm that would be upgraded to when you dry-run is not necessarily the charm that will be upgraded to when you do it for real | 09:26 |
| niemeyer | fwereade: I certainly wouldn't mind leaving the option for a second moment when we understand how it should really behave | 09:27 |
| fwereade | niemeyer, cool, I'll leave it out of the first attempt then :) | 09:28 |
| * niemeyer => breakfasting | 09:48 | |
| niemeyer | Invites sent | 11:00 |
| davecheney | ty | 11:00 |
| niemeyer | wrtp: ping | 11:02 |
| wrtp | niemeyer: pong | 11:02 |
| niemeyer | wrtp: Meeting time | 11:02 |
| wrtp | niemeyer: just quitting apps on my mac so i can use G+ | 11:02 |
| niemeyer | Any chance of a quick review on https://codereview.appspot.com/6501114/ so I can consider these bits done and move onto reviews? | 11:54 |
| fwereade | niemeyer, looking | 11:54 |
| niemeyer | fwereade: Cheers! | 11:54 |
| fwereade | niemeyer, LGTM, couple of trivial comments, ignore them if you like :) | 12:10 |
| niemeyer | fwereade: THanks! | 12:12 |
| wrtp | niemeyer: a little question: what's the use case for Watcher.Dying? | 12:15 |
| niemeyer | wrtp: See the machine watcher | 12:18 |
| niemeyer | wrtp: It's in use already | 12:18 |
| wrtp | niemeyer: wouldn't Dead be more appropriate? | 12:19 |
| wrtp | niemeyer: Dying kinda seems like it's an internal state transition of the watcher on its way to being dead. | 12:20 |
| fwereade | lunch, bbs | 12:28 |
| niemeyer | wrtp: Yeah, perhaps | 12:31 |
| niemeyer | wrtp: Do you see any edge cases where this might be a problem? | 12:31 |
| wrtp | niemeyer: no. i don't think there's any case when you want to know when a watcher is *about* to die | 12:32 |
| niemeyer | wrtp: Do you see any edge cases where using Dying might be a problem? | 12:32 |
| wrtp | niemeyer: it gives us leeway to change tomb to record more than one error in the future if we like | 12:33 |
| niemeyer | wrtp: Doesn't feel very compelling.. if we change tomb to behave differently, we might also change the watcher to behave differently | 12:34 |
| wrtp | niemeyer: and it just seems like something that doesn't need to be visible - the concept of dead is already there (Wait returns), but Dying is something different | 12:34 |
| wrtp | niemeyer: the tomb isn't part of the watcher interface | 12:34 |
| niemeyer | wrtp: Indeed.. but exposing Dead or Dying mean exactly the same as far as that perspective is concerned | 12:35 |
| wrtp | niemeyer: if we wait for Dead, we don't necessarily have to call Wait for it to die completely. | 12:36 |
| wrtp | niemeyer: if we wait for Dying, we do | 12:36 |
| niemeyer | wrtp: We don't call Wait, and we don't have to as far as I can see | 12:36 |
| wrtp | niemeyer: we call Stop | 12:36 |
| niemeyer | wrtp: Exactly | 12:36 |
| niemeyer | wrtp: Which we must | 12:36 |
| wrtp | niemeyer: even when it's told us it's dead? | 12:37 |
| niemeyer | wrtp: We must call Stop on state.Close, no matter what | 12:37 |
| niemeyer | wrtp: We're not going to be passing information between the watcher and the Close method | 12:37 |
| niemeyer | wrtp: Makes sense? | 12:40 |
| wrtp | niemeyer: i'm trying to think whether there might be a case where the message from, say, Watcher.Alive, might override the underlying error encountered by the presence.Watcher | 12:41 |
| wrtp | niemeyer: but perhaps that's simply an argument for including watcher.tomb.Err in the error message | 12:43 |
| niemeyer | wrtp: Yeah, possibly | 12:43 |
| niemeyer | wrtp: I was on the fence on that, but it does sound like a good idea from that perspective | 12:44 |
| wrtp | niemeyer: actually, Machine.WaitAgentAlive is a better example from that pov | 12:44 |
| wrtp | niemeyer: and if we're going to do that, then i think we *should* have Dead, not dying | 12:45 |
| wrtp | niemeyer: because we'll want to record any error encountered after it's been explicitly stopped. | 12:45 |
| niemeyer | wrtp: Sorry, I lost the leap | 12:45 |
| niemeyer | wrtp: The thing that caused the unit to die is there once Dying kicks | 12:46 |
| wrtp | niemeyer: yes, but the unit might have been explicitly stopped (no useful error message) but then actually encounter an error when shutting down, which we'd want to see | 12:47 |
| niemeyer | wrtp: Exactly, and that was the reason why it returned, and the reason why the cascading watcher was canceled | 12:47 |
| niemeyer | wrtp: It's as honest as it can be | 12:47 |
| wrtp | niemeyer: but if we're watching *Dying*, the error might not have been encountered yet | 12:47 |
| wrtp | niemeyer: because the watcher might only be just reacting to the dying message itself | 12:48 |
| niemeyer | wrtp: That's what I meant | 12:48 |
| niemeyer | wrtp: I'm fine to see a "returning because watcher was explicitly stopped" message if that's what actually happened | 12:49 |
| niemeyer | wrtp: The error from the watcher is an internal error, that will be visible from Close | 12:49 |
| wrtp | niemeyer: it may not | 12:49 |
| wrtp | niemeyer: because we might just have recorded the first error we encountered in a tomb before calling Close. | 12:50 |
| niemeyer | wrtp: Please read the Close method | 12:50 |
| niemeyer | wrtp: It returns the error from Stop from either watcher | 12:51 |
| niemeyer | wrtp: Besides that, to be honest if the watcher errored when terminating, and that error caused nothing to fail except the result of Stop, it's pretty boring error | 12:52 |
| niemeyer | wrtp: Feels a bit like we're hunting witches | 12:52 |
| wrtp | niemeyer: that may be true. but it's so easy to fix (use Dead rather than dying) that i'd rather have it work | 12:53 |
| niemeyer | wrtp: There's nothing to fix, so far | 12:53 |
| wrtp | niemeyer: it's this kind of code i was wondering about: http://paste.ubuntu.com/1198576/ | 12:53 |
| niemeyer | wrtp: This is artificial | 12:53 |
| niemeyer | wrtp: There's no such thing as | 12:53 |
| niemeyer | defer watcher.Stop(t.presenceWatcher, &t.tomb) | 12:53 |
| wrtp | niemeyer: oh, i'm probably misremembering | 12:53 |
| niemeyer | <niemeyer> wrtp: We don't call Wait, and we don't have to as far as I can see | 12:54 |
| niemeyer | <wrtp> niemeyer: we call Stop | 12:54 |
| niemeyer | <niemeyer> wrtp: Exactly | 12:54 |
| niemeyer | <niemeyer> wrtp: Which we must | 12:54 |
| niemeyer | <wrtp> niemeyer: even when it's told us it's dead? | 12:54 |
| niemeyer | <niemeyer> wrtp: We must call Stop on state.Close, no matter what | 12:54 |
| niemeyer | <niemeyer> wrtp: We're not going to be passing information between the watcher and the Close method | 12:54 |
| niemeyer | wrtp: I'm happy to change as it makes no difference, but there's no factual reason that I can see | 12:54 |
| wrtp | niemeyer: slightly more realistic, perhaps: http://paste.ubuntu.com/1198581/ | 12:56 |
| wrtp | niemeyer: but tbh nothing is gonna be deliberately closing the state underfoot apart from tests | 12:57 |
| wrtp | niemeyer: another reason to use Dead is it makes the error message more deterministic - w.Err() can change after Dying, but not after Dead. | 12:58 |
| niemeyer | wrtp: It can't in this case | 12:59 |
| niemeyer | wrtp: If there's an error with the watcher alive, it means we have a real error or we screwed up | 12:59 |
| niemeyer | wrtp: watcher.MustErr(st.watcher) | 13:00 |
| niemeyer | wrtp: That's there | 13:00 |
| niemeyer | wrtp: Which means that error won't change | 13:00 |
| niemeyer | wrtp: Ah, not in agent alive, nevermind | 13:01 |
| niemeyer | wrtp: Sure, anyway.. we can change | 13:01 |
| wrtp | niemeyer: i know it's a little thing, but worth doing IMHO | 13:02 |
| wrtp | niemeyer: thanks! | 13:02 |
| niemeyer | wrtp: np, can you do a CL with this? | 13:10 |
| wrtp | niemeyer: sure | 13:10 |
| niemeyer | wrtp: There's Dying both in mstate/watcher and presence | 13:10 |
| niemeyer | fwereade: Just sent a review | 13:13 |
| fwereade | niemeyer, cheers | 13:13 |
| niemeyer | fwereade: Great stuff, mostly trivials or questions for awereness | 13:14 |
| niemeyer | awareness | 13:14 |
| fwereade | niemeyer, cool | 13:14 |
| fwereade | niemeyer, (sometimes it's the questions for awareness that blow the whole thing out of the water, ofc ;)) | 13:14 |
| niemeyer | fwereade: LOL | 13:14 |
| niemeyer | fwereade: I don't think that's the case in this instance :-) | 13:14 |
| fwereade | niemeyer, good-oh :) | 13:15 |
| fwereade | niemeyer, sent responses, I'll gtw on the non-controversial ones :) | 13:22 |
| niemeyer | fwereade: Re-proposed https://codereview.appspot.com/6501114 too | 13:30 |
| * fwereade looks | 13:30 | |
| fwereade | niemeyer, ok, about changes in pending -- can a sync happen on a different goroutine? | 13:33 |
| niemeyer | fwereade: nope | 13:33 |
| niemeyer | fwereade: It's all done in a single goroutine | 13:33 |
| fwereade | niemeyer, ok great :) | 13:33 |
| niemeyer | fwereade: Yeah, it's complex enough without concurrency issues :) | 13:33 |
| fwereade | niemeyer, the trouble is that it makes sense now, so I can't say what would have made it easier to begin with :) | 13:34 |
| wrtp | fwereade: i think that once you've got used to that kind of pattern, it's fairly easy to spot and verify when you're reading the code. | 13:35 |
| fwereade | niemeyer, LGTM | 13:36 |
| niemeyer | fwereade: LGTM too (and that's not just an exchange, promise ;) | 13:40 |
| fwereade | niemeyer, haha | 13:40 |
| niemeyer | fwereade: I'll check the new comment when you submit | 13:41 |
| niemeyer | wrtp: I'm pushing a trivial branch with the suggested s/Dying/Dead/ | 13:47 |
| wrtp | niemeyer: ok, thanks, sorry, i'm still debugging a change to the authorize ec2 branch | 13:48 |
| niemeyer | wrtp: np, that's kind of the point.. you're surely doing more interesting stuff and I'd rather unblock you | 13:48 |
| wrtp | niemeyer: that's appreciated, thanks | 13:48 |
| fwereade | niemeyer, btw, in case you missed it, the one you reviewed is still blocked on https://codereview.appspot.com/6489083/ | 13:48 |
| niemeyer | wrtp: np | 13:49 |
| niemeyer | fwereade: I've half-missed it | 13:49 |
| niemeyer | fwereade: I was already reviewing when I noticed it had a pre-req | 13:49 |
| fwereade | niemeyer, np | 13:51 |
| niemeyer | wrtp: https://codereview.appspot.com/6489111 | 13:55 |
| wrtp | niemeyer: reviewed | 13:56 |
| niemeyer | wrtp: cHeers | 13:57 |
| fwereade | niemeyer, re ModeUpgrading: it's perfectly legitimate to enter ModeUpgrading in an error state, and all the hook-error-related logic is now in Uniter itself -- I'm going to just drop mention of errors in the ModeUPgrading comment | 14:03 |
| niemeyer | fwereade: Sounds good, that was my confusion.. it's talking about errors despite it not really doing anything about them, or even needing anything given what you say | 14:04 |
| niemeyer | niemeyer> fwereade: Sounds good, that was my confusion.. it's talking about errors despite it not really doing anything about them, or even needing anything given what you say | 14:09 |
| niemeyer | fwereade: By the way, I had to look over Abide in the dictionary, thanks :-0 | 14:10 |
| niemeyer | :-) | 14:10 |
| wrtp | niemeyer: a trivial ec2test fix: https://codereview.appspot.com/6501117/ | 14:11 |
| niemeyer | fwereade: Seems very appropriate, btw | 14:12 |
| fwereade | niemeyer, fantastic, I just couldn't get over a feeling that I was being hipster-weirdy, despite not being able to come up with a better term :) | 14:13 |
| niemeyer | fwereade: Steady would be another choice | 14:13 |
| fwereade | niemeyer, I feel that once I've called it an operation it kinda needs to be a verb | 14:14 |
| niemeyer | fwereade: makes sense | 14:14 |
| niemeyer | wrtp: So what's up there? | 14:14 |
| wrtp | niemeyer: when i wrote ec2test i thought that (as according to the docs) you could not specify source group names without also specifying an owner id. | 14:15 |
| wrtp | niemeyer: that's not true, and it's nice if we can specify a name only. | 14:15 |
| niemeyer | wrtp: Okay, I had the same impression | 14:15 |
| niemeyer | wrtp: LGTM if it reflects reality | 14:16 |
| wrtp | niemeyer: it means we don't need a special-case hack for authorizing self in ec2.environ.ensureGroups. | 14:16 |
| wrtp | niemeyer: and it does seem to work live. perhaps i should include a server test to make sure within the ec2 package itself. | 14:17 |
| niemeyer | fwereade: Sent comment on https://codereview.appspot.com/6489083/ | 14:52 |
| niemeyer | comments | 14:52 |
| fwereade | niemeyer, great, tyvm | 14:52 |
| niemeyer | wrtp: Sounds good | 14:52 |
| niemeyer | fwereade: np, one point I'd appreciate talking for understanding only, otherwise only boring/trivial stuff | 14:52 |
| fwereade | niemeyer, the SetCharm/Write/Deploy? | 14:54 |
| fwereade | niemeyer, my feeling is that because a Deploy is always preceded by a SetCharm, we only need to commit to the upgrade state once we're about to write to the actual deployment directory | 14:56 |
| fwereade | niemeyer, if we happen to SetCharm twice due to unhelpful process bounces, it's no big deal (in fact SetCharm will just return) | 14:58 |
| niemeyer | fwereade: Why isn't it simply Deploy(u.charm, url), or something similar? | 14:58 |
| fwereade | niemeyer, ha, good question | 14:59 |
| niemeyer | fwereade: I'm not finding the place where deploy() is called | 14:59 |
| fwereade | niemeyer, primarily because the sheer amount of code in one method was getting me down, and it seemed like a good idea at the time | 14:59 |
| * niemeyer looks at the raw diff | 15:00 | |
| fwereade | niemeyer, ModeInstalling is the only place in that tree, I think | 15:00 |
| fwereade | niemeyer, sorry to be talking about upgrade above, that's the way I tend to think about it -- but, yes, that CL doesn't include any upgrading | 15:02 |
| niemeyer | fwereade: That's certainly fine | 15:03 |
| wrtp | niemeyer: ok, the functionality is now tested live (and a couple of live tests were fixed in the process) | 15:03 |
| wrtp | niemeyer: https://codereview.appspot.com/6501117/ | 15:03 |
| niemeyer | fwereade: Why we use the urls that we SetCharmURLs again? | 15:04 |
| niemeyer | wrtp: Cheers | 15:04 |
| fwereade | niemeyer, sorry, cannot parse | 15:05 |
| niemeyer | fwereade: Trying to figure what we do with the info we give deployer.SetCHarm | 15:05 |
| fwereade | niemeyer, all we use it for *directly* is to avoid setting the same charm again; indirectly it's also returned from u.charm.ReadURL or whatever it's called | 15:06 |
| fwereade | niemeyer, which itself is used to compare against service-charm-change events to determine whether or not we care | 15:08 |
| fwereade | niemeyer, u.charm.ReadCharmURL | 15:09 |
| niemeyer | fwereade: Now that I went looking for them, it seemed slightly surprising to have ReadCharmURL/WriteCharmURL on GitDir.. | 15:09 |
| niemeyer | fwereade: We should probably move those to functions later | 15:09 |
| fwereade | niemeyer, hmm, it *is* a charm.GitDir | 15:09 |
| fwereade | niemeyer, it seemed like a great idea to me at the time | 15:10 |
| fwereade | niemeyer, I presume you're seeing an ugliness I'm missing | 15:10 |
| niemeyer | fwereade: GitDir is not about charm at all, except for those two trivial functions, where one of them is a single line | 15:10 |
| fwereade | niemeyer, well, I'm perfectly happy to move them out, but it feels *slightly* more than coincidental that both GitDir clients find them useful | 15:11 |
| niemeyer | fwereade: Which is great, I'm not complaining about where we are | 15:11 |
| niemeyer | fwereade: These functions should definitely be within charm, and they can easily take a GitDir | 15:12 |
| fwereade | niemeyer, ok, that SGTM :) | 15:12 |
| niemeyer | fwereade: The logic is the same.. it's just that git has no read-charm command :) | 15:13 |
| fwereade | niemeyer, true :) | 15:13 |
| niemeyer | fwereade: Anyway, that was a derail, sorry | 15:13 |
| fwereade | niemeyer, np at all, nice easy trivial for later | 15:13 |
| wrtp | weird bzr behaviour: http://paste.ubuntu.com/1198834/ | 15:14 |
| wrtp | i can't make it push the branch | 15:14 |
| wrtp | which causes lbox to fail when proposing | 15:14 |
| wrtp | it works if i fork the branch, delete the old one and rename to the old name | 15:15 |
| wrtp | niemeyer: any ideas? | 15:15 |
| niemeyer | fwereade: So, the separation definitely sounds sensible.. my memories were betraying me | 15:16 |
| niemeyer | fwereade: I thought SetCharm was doing something else | 15:16 |
| fwereade | niemeyer, np, mine do the same quite frequently ;p | 15:16 |
| niemeyer | fwereade: I'm wondering how we can name it in a way that feels like SetCharm and Deploy are complementary operations, that operate on different backing data and do not conflict | 15:18 |
| fwereade | niemeyer, Prepare/Run perhaps? | 15:18 |
| niemeyer | fwereade: Hmm.. Stage+Deploy? | 15:18 |
| fwereade | niemeyer, +1 | 15:18 |
| niemeyer | fwereade: Super | 15:18 |
| niemeyer | wrtp: Looking | 15:19 |
| niemeyer | wrtp: % bzr commit -m 'change to try to force bzr to remember push loc' | 15:19 |
| niemeyer | wrtp: commit doesn't do that | 15:19 |
| niemeyer | wrtp: push --remember does that | 15:19 |
| fwereade | niemeyer, I think I'll propose a trivial rename branch from trunk for the ones we just discussed | 15:19 |
| wrtp | niemeyer: i tried push --remember - it didn't do anything. so i thought i'd try a source change too. | 15:20 |
| niemeyer | wrtp: Understood, but changing the history has no relation to metadata | 15:20 |
| wrtp | niemeyer: ok, thanks. so ignore that line and you'll see that there's a problem. | 15:21 |
| wrtp | niemeyer: (i think) | 15:21 |
| niemeyer | wrtp: See the .bzr/cobzr/<name>/.bzr/branch/branch.conf file | 15:22 |
| niemeyer | wrtp: and see where it is pointing to | 15:22 |
| niemeyer | fwereade: Cool | 15:23 |
| niemeyer | fwereade: So, regarding the WriteState | 15:23 |
| fwereade | niemeyer, yes | 15:23 |
| wrtp | niemeyer: push_location = file:///home/rog/src/go/src/launchpad.net/juju-core/.bzr/cobzr/051-authorize-internal-traffic/ | 15:23 |
| wrtp | niemeyer: which looks very odd | 15:24 |
| niemeyer | fwereade: now that my mind is not totally wrong :) | 15:24 |
| fwereade | niemeyer, the underlying idea is to wait as long as possible before we persist the fact that we're upgrading to charm X | 15:24 |
| wrtp | niemeyer: i'll try and reproduce the problem from scratch with lbox -v | 15:24 |
| fwereade | niemeyer, the motivation for doing so is pretty weak, to be fair | 15:25 |
| niemeyer | fwereade: What is it? | 15:25 |
| niemeyer | wrtp: This isn't about lbox, or even cobzr | 15:25 |
| niemeyer | wrtp: This is plain bzr | 15:25 |
| wrtp | niemeyer: ok | 15:25 |
| fwereade | niemeyer, very specific situation: uniter falls down having Staged a new charm, and the user pushes a new charm version before it comes up again -- this means that it will see the newest charm and upgrade directly to that | 15:26 |
| niemeyer | wrtp: I don't know why it is misbehaving | 15:26 |
| niemeyer | wrtp: Try to delete the push line there | 15:26 |
| fwereade | niemeyer, the adverse consequences of just installing the first charm then the second one are pretty minimal to be fair | 15:26 |
| wrtp | niemeyer: when i fork a fresh branch, the push line is gone. but then it reappears. | 15:26 |
| niemeyer | fwereade: Doesn't it also mean it'll download the charm twice on the other scenario? | 15:27 |
| fwereade | niemeyer, downloads won;t be repeated; stages won;t be repeated | 15:27 |
| fwereade | niemeyer, it's easy to detect prior completion of each of those | 15:27 |
| niemeyer | fwereade: Cool, I'm happy with the current logic, thanks | 15:28 |
| fwereade | niemeyer, BundlesDir caches, and Stage checks for the existing charm url | 15:28 |
| fwereade | niemeyer, sweet | 15:28 |
| wrtp | niemeyer: yeah you're right, it's just bzr. http://paste.ubuntu.com/1198862/ | 15:29 |
| niemeyer | wrtp: Very weird, either way | 15:30 |
| wrtp | niemeyer: indeed | 15:31 |
| niemeyer | Stepping out for lunch, biab | 15:34 |
| fwereade | wrtp, can I get a LGTM on the trivial I just discussed? https://codereview.appspot.com/6489112 | 15:37 |
| wrtp | fwereade: LGTM | 15:39 |
| fwereade | wrtp, lovely, thanks | 15:39 |
| === hazmat is now known as kapilt | ||
| wrtp | fwereade: was there a particular reason you didn't make the "run uniter" branch run the upgrader task? | 17:08 |
| * niemeyer waves | 17:30 | |
| * wrtp waves back to niemeyer | 17:39 | |
| wrtp | niemeyer: ec2test fix submitted, thanks. | 17:39 |
| niemeyer | wrtp: Thank you! | 17:43 |
| wrtp | Aram: yo! | 17:44 |
| Aram | hi. | 17:44 |
| niemeyer | Aram: Hi | 17:44 |
| Aram | sorry everybody. | 17:44 |
| Aram | had internet troubles :(. | 17:44 |
| Aram | niemeyer: have you seen my latest review for machine watcher? | 17:46 |
| Aram | my comment about TxnRevno | 17:46 |
| niemeyer | Aram: Yes, just answering it now | 17:46 |
| wrtp | Aram: we should all swap mobile numbers so we can have an alternative comms channel when something like that happens | 17:47 |
| Aram | wrtp: agreed. | 17:47 |
| wrtp | niemeyer: it's a good day for bzr oddities: http://paste.ubuntu.com/1199119/ | 17:50 |
| niemeyer | Aram: Responded | 17:52 |
| niemeyer | wrtp: lp:launchpad.net? | 17:53 |
| wrtp | niemeyer: oh jeeze, i just couldn't see it! thanks. :-| | 17:54 |
| niemeyer | wrtp: I know how it goes | 18:00 |
| niemeyer | wrtp: Sometimes everything just feels broken and it's hard to see even the typos | 18:01 |
| wrtp | niemeyer: yeah | 18:01 |
| wrtp | niemeyer: i kinda new it was something obvious but i just couldn't see it! | 18:01 |
| niemeyer | fwereade: Is there anything I can do on https://codereview.appspot.com/6489083 to help out, or are you working on it still? | 18:03 |
| wrtp | niemeyer: can i put in a small request for a review of https://codereview.appspot.com/6501106/ ? i'm using it as a prereq for quite a lot of stuff. | 18:05 |
| niemeyer | wrtp: Will check it right now | 18:05 |
| wrtp | niemeyer: thanks | 18:05 |
| niemeyer | wrtp: done | 18:35 |
| wrtp | niemeyer: thanks a lot | 18:37 |
| niemeyer | wrtp: My pleasure, glad to see the progress there | 18:37 |
| wrtp | niemeyer: there's also https://codereview.appspot.com/6495086/ which you mostly reviewed about a week ago, but i changed it a bit since then. | 18:38 |
| wrtp | niemeyer: i think you'll like it :-) | 18:38 |
| niemeyer | wrtp: Cheers, I am going through the review list.. if you're not blocked on it, I'll get to it soon | 18:47 |
| wrtp | niemeyer: it is a prereq of another branch which i'm building on in turn, but i wouldn't say i'm blocked on it as such. | 18:47 |
| wrtp | niemeyer: i'm off now. see you tomorrow & have fun. | 18:56 |
| niemeyer | wrtp: have a good one | 18:58 |
| niemeyer_ | OMG | 21:23 |
| niemeyer_ | Not only the queue is clean, but we have 9 branches on the runway to land | 21:23 |
| === kapilt is now known as hazmat | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!