fo0barubuntulog test05:12
TheMuerog: morning08:32
rogTheMue: hiya!08:32
rogTheMue: feeling better, i hope08:32
TheMuerog: yep, yesterday already almost through with it, today feeling fine. thx.08:33
rogTheMue: cool08:33
rogTheMue: glad to hear it!08:33
TheMuerog: already proposed the next charm changes also containing your _ wishes. ;)08:34
rogTheMue: thanks08:34
rogTheMue: saw that08:34
TheMuerog: my pleasure08:35
TheMuerog: btw, got another 'infect'.08:35
rogTheMue: infect?08:36
TheMuerog: during studies i've learned scheme, but now i' trying lisp. ;)08:36
rogah. CL?08:36
rogSBCL is the one to use08:36
rogbaroque but interesting with it08:36
TheMuerog: yep, choosen sbcl as a start.08:37
rogTheMue: the hyperspec is the invaluable reference - i used it all the time08:37
TheMuerog: and i want to play a bit with actors in lisp, found some docs and a lib.08:38
rogTheMue: for your amusement, here was a little library i did in CL some time back: http://common-lisp.net/project/cl-xmlspam/08:38
TheMuerog: ah <click>08:38
rogTheMue: i ported russ's08:39
rogi ported russ's C channel communications code to CL too.08:39
rogTheMue: never entirely satisfactory - it really needs lightweight threads, like Go.08:39
TheMuerog: i'll see if i can do something like actors running based on thread pools08:41
wrtpTheMue: so no first-class channels - sending messages to processes like in erlang?08:41
TheMuewrtp: yep, more like that08:42
TheMuewrtp: and like scala08:42
wrtpTheMue: right.08:42
wrtpTheMue: (i haven't looked at scala much)08:43
TheMuewrtp: i only for a short article i wrote more than a year ago, not very deep08:43
wrtpTheMue: the book to buy for getting into CL is "Practical Common Lisp", if you haven't already got it.08:44
TheMuewrtp: i dislike all those langs based on the jvm, they tend to be too weak due to the (wished) interaction with the java libs.08:44
wrtpTheMue: it's great. and doesn't try to hide the dubious bits08:44
wrtpTheMue: yeah. same with .net languages08:45
wrtpTheMue: i played with F# for a bit08:45
TheMuewrtp: full ack08:45
TheMuewrtp: i got "Land Of Lisp" for a review. but if the infect gets deeper i'll buy your book. ;)08:46
TheMuewrtp: i only read about f#, but it looked interesting too08:46
TheMuewrtp: and i still like erlang (used it for two years).08:47
wrtpTheMue: it's a classic. and extremely useful for finding out how to get around the bizarre file path handling for example08:47
TheMuewrtp: so, have to leave for a few minutes, banking. biab08:48
wrtpTheMue: c u08:49
wrtpsomething odd is going on with this machine: http://paste.ubuntu.com/853732/09:34
TheMueback again09:57
wrtpTheMue: are you seeing codereview.com being slow currently?11:01
TheMuewrtp: no, today they have been fine. but had the too last week.11:02
* wrtp really doesn't like it when he makes lots of changes in response to a review... and then finds out they were made in the wrong branch.11:18
wrtpniemeyer: yoyo!11:26
wrtpniemeyer: responses made to both reviews, BTW.11:26
wrtpi hope you don't mind, i went for "k" rather than "pk" :-)11:27
niemeyerwrtp: Thanks!11:28
niemeyerwrtp: That's fine too11:28
niemeyerwrtp: Was just trying to make them consistent and distinct among themselves11:28
wrtpniemeyer: yeah, thought so.11:28
wrtpniemeyer: i like permKey BTW11:28
niemeyerwrtp: Sweet11:29
TheMueniemeyer: Already took a first look into https://codereview.appspot.com/5671055/?11:55
TheMueniemeyer: hiya btw11:55
niemeyerTheMue: Heya!11:55
niemeyerTheMue: Not yet, but you're my first priority today.. I'll just finish a meeting with Dave Cheney, and will be in your reviews11:56
TheMueniemeyer: great, thx11:56
TheMueniemeyer: just for info, weekly update leeds to zookeeper compiling troubles12:02
TheMueoh, wife calls for lunchtime12:02
niemeyerTheMue: The fix is already up for review12:04
niemeyerTheMue: and you'll have to upgrade to Go tip as well12:04
niemeyerTheMue: There's a bug in cgo itself that I fixed yesterday12:04
TheMueniemeyer: ok, thix, will switch to tip12:29
wrtpTheMue: actualy the fix is in weekly12:37
wrtpTheMue: (the newest weekly)12:37
TheMuewrtp: so tip should contin it too, shouldn't it?12:38
wrtpTheMue: sure. but i think we generally use weekly if it works.12:38
TheMuewrtp: hmm, if i recall it right, somebody named rog told me we use tip.12:39
TheMuewrtp: ;)12:39
wrtpTheMue: only occasionally, when things are broken with weekly :-)12:40
wrtpTheMue: ...as was the case on that previous occasion12:41
TheMuewrtp: thankfully an update-golang release|weekly|tip is enough for a full reinstall including the external packages12:42
wrtpTheMue: yeah, the go tool makes things much much easier. bliss.12:43
wrtpTheMue: i usually run all.bash though just in case the compilers have changed12:43
TheMuewrtp: me too, but it's inside the script above, together with the go get's12:46
wrtpTheMue: ah, it's your script. i though you just meant "hg update weekly"12:47
wrtpTheMue: (which does work usually in fact)12:47
TheMuewrtp: no, the script does the hg update, the all.bash and some clean go get12:47
TheMuewrtp: i'm lazy, ol' admin. ;)12:48
TheMuewrtp: doing something more than two, three times needs automation12:49
wrtpTheMue: what's the go get for?12:49
wrtpTheMue: to update to the required package versions?12:49
TheMuewrtp: yep, I earlier had troubles that once fatched code is only recompiled, not fetched again after release changes12:50
wrtpTheMue: yeah, i can see that. i don't usually have that problem though - i'll do get -u when a package stops working :-)12:51
TheMuewrtp: is a go build of own sources now intelligent enough to do a go get on 3rd party packages?12:51
wrtpTheMue: ... which makes it faster to switch versions.12:51
wrtpTheMue: a "go get -u" you mean?12:52
TheMuewrtp: yep, my script does a go get -u too12:52
wrtpTheMue: i don't think it's possible for it to know if the appropriate version has changed.12:52
wrtpTheMue: (of a given package, with respect to the current Go version, i mean)12:53
TheMuewrtp: would be nice. "hey, i'm building with rel 1 and import 3rd party pkg a. let's check if it has the according rel, otherwise update it on the fly."12:53
wrtpTheMue: i think if you do 'go get -u .' it should work12:54
TheMuewrtp: yeah, it does, but you have to do it manually.12:54
TheMuewrtp: inside of a go build it would be nice12:55
TheMuewrtp: enjoy12:55
niemeyerTheMue: So, let me see your branch13:47
* niemeyer browses the review list13:47
TheMuefwereade_: thx for the review, the other branch with your comment is in https://codereview.appspot.com/5690051/14:57
fwereade_TheMue, thanks; but I'm not clear which order they're meant to be merged in14:57
fwereade_TheMue, I'm sure I could figure it out but I'm lazy -- it would be good to set prereqs even if we don't yet get nice diffs out of it14:58
TheMuefwereade_: while point 1 is related to the testing dir question what exact problem do you have with .. in path?14:58
fwereade_TheMue, just that I'm suspicious that things will move :p14:58
TheMuefwereade_: yeah, understand, would be nice if the order/dependency could be seen easily14:58
niemeyerTheMue: Review sent15:01
TheMueniemeyer: thx for review. you get a compiling error? which kind?15:01
niemeyerTheMue: I don't think I said that15:01
TheMueniemeyer: ok, than i misinterpreted a comment15:01
TheMueniemeyer: so the state.Charm should implement the charm.Charm interface?15:02
niemeyerTheMue: Yes, and I think it already does15:03
TheMueniemeyer: hehe, maybe by accident15:03
TheMueniemeyer: it's the first time in state we're implementing an external interface, so i wondered15:04
niemeyerTheMue: Yeah, that's fine.. charm is kind of special in that we have several implementations of the interface15:04
niemeyerWe have another one in the store as well15:05
niemeyerSo 4 implementations right now15:05
* TheMue likes interfaces15:05
niemeyerTheMue: I like _Go_ interfaces.. specifically.. :-)15:05
niemeyerI've had not-so-great experiences before with other kinds of interfaces15:06
niemeyerZope interfaces comes to mind, for instance..15:08
TheMueniemeyer: never played with zope15:09
niemeyerI'll head to lunch, biab15:11
rogpeppenetwork has been playing up all day15:15
rogpeppefwereade_: you gotta review15:30
fwereade_rogpeppe, tyvm15:30
rogpeppefwereade_: you might not when you see all the comments!15:31
rogpeppefwereade_: looking good though, in general15:31
fwereade_rogpeppe, heh, lots of comments beat just one saying "utterly hopeless; rejected, and shame on you" or equivalent :p15:32
rogpeppefwereade_: lol15:32
rogright, i'm gonna reboot.15:37
rogwell, ubuntu boot is quick, but shutdown...15:45
fwereade_rog, just a thought... if pstate were called pinfo, would you be happier about keeping path in there?15:52
rogfwereade_: i don't see why you want path in there really. it just saves a parameter in two functions.15:52
rogfwereade_: i'd be happier with a watcher type to gather together more params - i think things would look cleaner then.15:53
fwereade_rog, I admit that I originally put it in there because I was getting annoyed about the number of params ;)15:53
fwereade_rog, I'll experiment a bit15:54
rogfwereade_: if you pass watcher by value, you won't even need to incur an allocation - it'll be exactly to equivalent to passing the values as arguments.15:55
fwereade_rog, the tyvm holds, nice review16:06
fwereade_rog, I'm not so sure about the loop/goroutine question though16:06
rogfwereade_: no?16:06
rogfwereade_: i don't see why you need to start a new goroutine each time through16:07
fwereade_rog, forces are that (1) there are far more cases in which I want to break out of the loop than to continue looping, and (2) it seems to me that if I just recurse I'll eventually use an impolite amount of stack16:08
fwereade_rog, (1) hence not-quite-right as a loop, (2) hence goroutine16:09
fwereade_rog, sane or crackful? :p16:11
rogfwereade_: one mo, i'll paste the kind of thing i'm thinking of16:12
rogfwereade_: http://paste.ubuntu.com/854172/16:12
fwereade_rog, that's basically what I had before I decided the loop was ugly (without the break loop, which doesn't feel to me like it really improves clarity)16:14
rogfwereade_: yeah, it looks better without the loop label: http://paste.ubuntu.com/854177/16:15
rogfwereade_: but i think the loop is good - you're wanting to loop, so why not use one?16:16
fwereade_rog, hm, with for p.alive, that's definitely nicer16:16
rogfwereade_: oops, needs a p.alive=false in the DELETED case16:17
fwereade_rog, details details :)16:17
fwereade_rog, what about awaitAlive though? the looping is definitely exceptional in that case16:17
* rog has a look16:17
fwereade_rog, hm, still, for consistency's sake I might change that one anyway16:19
rogfwereade_: i think you can use exactly the same structure to good effect: http://paste.ubuntu.com/854183/16:19
rogfwereade_: they're both less lines of code, easier to read (IMHO) and more efficient... what's not to like? :-)16:20
fwereade_rog, yeah, exactly, with the loop conditions they are much nicer16:22
fwereade_rog, thanks :)16:22
rogfwereade_: np. (writing this kind of code with channels is nice, ain't it?)16:22
fwereade_rog, yeah, I'm really enjoying it :)16:23
rogfwereade_: good. that's what we want to hear :-)16:23
rogfwereade_: the main issue that probably needs discussion is whether unoccupying a node should delete it.16:24
fwereade_rog, ah yeah, I meant to mention that16:24
rogfwereade_: i'm tending towards the point of view that it shouldn't16:24
fwereade_rog, the raciness you sadly note has nothing to do with node clearing16:24
fwereade_rog, I don;t think it's sensible to assume that a presence node we want to watch will automatically exist16:25
rogfwereade_: if you were guaranteed that node existed, then you could just do GetW - no need for the ExistW call16:25
fwereade_rog, who says the Pinger even got started?16:25
rogfwereade_: i think the node should be created before the Pinger is started.16:25
rogfwereade_: so when some structure is created, a node is created for the watch node. and then a pinger and a watcher can rendezvous on it.16:26
fwereade_rog, well, it is, first thing on pinger creation, before run (so we can get any errors out quickly and easily, if they're going to happen)16:26
fwereade_rog, but... doesn't this just shuffle the raciness around?16:26
rogfwereade_: yeah, but there's no error if a watcher is watching a bad path16:26
fwereade_rog, who's responsible for creating that node?16:27
rogfwereade_: i don't think so.16:27
rogfwereade_: the state code.16:27
rogfwereade_: so if you're an agent, you can do an ExistsW if you like to determine when some structure comes into place (same way we watch the init node), and then run a pinger or a watcher on a node within the structure16:28
rogfwereade_: it's a slightly different approach i know, but i think it might make sense16:28
rogfwereade_: one mo, i've got to go and help carmen turn over the contents of a compost bin. back in 5.16:29
fwereade_rog, np, thinking16:30
niemeyerfwereade_: Can't awaitDead and awaitAlive be a single loop?16:30
niemeyerfwereade_: I don't have anything concrete yet, but my gut feeling about all those helper functions is that the problem itself shouldn't be so complex16:31
fwereade_niemeyer, hm, maybe, rog's suggested changes might make me able to do that clearly16:31
niemeyerfwereade_: I may be on crack.. so don't bother too much.. I'll do a more careful review on the logic once you're happy with it16:31
fwereade_niemeyer, still worth a look16:31
fwereade_niemeyer, cheers16:32
fwereade_niemeyer, I'm not sure that'd work tbh -- the timeout in awaitDead wouldn't really play nicely with everything else16:34
fwereade_niemeyer, or maybe I just can't see it :)16:34
niemeyerfwereade_: How's that any different from the timeout on awaitAlive?16:34
fwereade_niemeyer, what timeout?16:34
niemeyerfwereade_: The same that exists on awaitDead.. why is there a timeout on one and not the other?16:35
fwereade_niemeyer, the timeout is ony useful for detecting the case when updates have stopped16:35
niemeyerfwereade_: Why?16:35
niemeyerfwereade_: This isn't rhetorical, btw.. you may be right.. I'm brainstorming.16:35
fwereade_niemeyer, there's no timeout on awaitAlive because we don't need to do anything weird to support getting back a create/change at somepoint in the future16:36
fwereade_niemeyer, there's a timeout on awaitDead because that's the only way I could see to tell when a watch *hasn't* fired16:36
niemeyerfwereade_: How do I wait for an agent to come live?16:36
fwereade_niemeyer, ...call AliveW and wait for the channel to fire if it wasn't already alive?16:37
niemeyerfwereade_: Ok, sorry, I misunderstood what you meant by timeout then16:38
fwereade_niemeyer, ah, sorry :)16:38
rogniemeyer: i'm thinking that all the logic becomes simpler if we assume that the node exists before starting.16:39
rogniemeyer: so rather than deleting the node at the end, we'd just set it to empty16:40
niemeyerrog: How can we assume it exists?16:40
fwereade_rog, even if we did, who would delete the node in the end?16:40
rogniemeyer, fwereade_: the node doesn't exist in isolation, surely? it's part of a larger zk structure that represents something, no?16:41
niemeyerrog: Sorry, I'm out of context and don't know what you're trying to say16:41
niemeyerrog: The node is within zookeeper.. it's not part of any structure16:41
rogniemeyer: i'm talking about a directory structure within zk16:42
fwereade_rog, I can see how it could work for machine nodes, but making it work for unit relation nodes is giving me a headache16:42
niemeyerrog: The node is within zookeeper.. it's not part of anything else, as far as the presence package is concerned16:42
fwereade_rog, and besides, I'd far prefer to make foo responsible for communicating foo's status without anyone else's help16:42
niemeyerfwereade_: It shouldn't make a difference16:42
rogniemeyer: that's fine. i'm just thinking that the initial waiting for the node to come into being can be done outside the presence package.16:43
fwereade_niemeyer, it's not creation that makes my head hurt so much as it is deletion16:43
niemeyerfwereade_: The presence node is context-less.. the package needs to know a path where it's supposed to exist, and it can assume that the parent exists, but nothing else.16:43
niemeyerfwereade_: What's the issue with creation?16:43
fwereade_niemeyer, there isn't one16:43
niemeyerfwereade_: There isn't one what?16:44
fwereade_niemeyer, an issue with creation16:44
niemeyer<fwereade_> niemeyer, it's not creation that makes my head hurt so much as it is deletion16:44
niemeyerfwereade_: Ah, I inverted the sentence16:44
rogfwereade_: why's deletion an issue? deletion would mean the node becomes dead as now.16:44
niemeyerfwereade_: You mean deletion is the problem.. what's the issue with deletion?16:44
rogfwereade_: (for instance when the containing directory and its children is deleted)16:45
fwereade_rog, niemeyer: who is responsible for it, and how do they arrange it with the unit agent, which may be behind schedule and have a bunch of other hook queued up before it can actually process a departure16:45
rogfwereade_: responsible for what?16:46
fwereade_rog, deleting the node16:46
fwereade_rog, I presume we don't want to keep nodes around forever just because something once used it16:46
rogfwereade_: the caller of the presence package. the idea is that responsibility for the node's creation and deletion is up to the caller.16:47
rogfwereade_: the presence package would purely manage pings on an existing node.16:47
rogfwereade_: i may be smoking more crack than usual, of course.16:47
niemeyerfwereade_: You only have to worry about it in the sane cases.. e.g. if Kill() is called16:47
niemeyerfwereade_: If there's a hard crash and the agent dies, there will be a bunch of trash around those nodes that has to be collected16:47
niemeyerfwereade_: The original code is obviously unable to do with it, since it may have gone forever16:48
niemeyerrog: The presence package should delete the node in the case where the call site is requesting the pinger to die in a way that notifies watchers16:49
fwereade_niemeyer, ok, unstated assumption: without a good reason, the same thing should handle creation and deletion. sane?16:49
rogfwereade_: yes16:49
TheMueniemeyer: i've got no prob dropping readCharm() and let Service use State directly. but in this case to keep it consistent i would like to change all entities from getting the ZK conn from state now to getting the State itself.16:49
rogniemeyer: i'd just set the contents to empty to do that16:49
niemeyerrog: No reason, I believe.. removal is a pretty good way to flag it16:50
rogniemeyer: rather than deleting the node.16:50
TheMueniemeyer: so i would change it in Machine, Unit and the now comming new ones too16:50
fwereade_rog, ok, but you're saying that (1) *something* unstated should create the node in the first place, and that other *something* should delete it at the end, and we shouldn't have a Kill (or at least not one that deletes the node)16:50
fwereade_rog, what would that something be?16:50
niemeyerTheMue: Yes, that's a good idea, but please do it in a follow up tiny branch that does just that16:50
niemeyerTheMue: Rather than piling up the unrelated change16:50
rogniemeyer: the nice thing about assuming that the node already exists is that you have some sanity check on whether it might ever change in the future, which we don't for a non-existent path.16:51
TheMueniemeyer: ok, this will be only the first step with Charm16:51
TheMueniemeyer: and Service ;)16:51
niemeyerrog: I don't understand what's the advantage. I agree with fwereade_.16:51
niemeyerrog: You seem to be saying that the nice thing about having someone else creating the node is that someone else has to do exactly the same logic that would otherwise be done inside the presence node, which to me makes no sense.16:52
fwereade_rog, yeah, niemeyer put it better than I managed16:52
rogi think i'm saying that other things know how to wait for existence (and that can imply other things too), but the pinger is the place that does keepalives.16:53
rogbut i don't mind too much. it was just an idea.16:54
niemeyerrog: Still don't see what you mean.. the pinger is the thing that knows how to deal with a presence node to ping it, and that includes creation.16:55
niemeyerfwereade_: Btw, let's call StartPing as StartPinger os StartPinging.. StartPing feels weird16:55
rogniemeyer: it *can* include creation, but i don't think it has to.16:55
rogniemeyer: NewPinger seems ok to me...16:55
niemeyerrog: No, we can have a better interface as well and move things out of it16:55
niemeyerrog: and then we have a pinger that doesn't know how to ping.16:55
niemeyerfwereade_: Ok.. let's please have creation within the pinger.. there's no real argument that I can see to not do it.16:56
rogfair enough16:56
fwereade_niemeyer, I'm happy with that :)16:56
niemeyerfwereade_: And StartPinger, please..16:56
fwereade_niemeyer, possible convention counterargument: time.NewTimer, time.NewTicker16:57
rogfwereade_: given that this is the presence package, i was just wondering if the "p" prefix is useful in pstate? just type state might be fine. and it makes the capitalisation less awkward.16:58
niemeyerfwereade_: Let's please use Start.. New lacks the idea that this is going to be alive doing something rather than just creating an object16:58
rogniemeyer: NewTicker??16:59
niemeyerrog: I didn't name this one16:59
fwereade_niemeyer, fair enough16:59
rogniemeyer: it's seems a fine precedent to me, but there y'go. lots of New* functions create active things.16:59
niemeyerrog: I'm comfortable enough to improve existing conventions17:00
jimbakerhazmat, g+ mtg?17:00
rogniemeyer: i really don't think that's a great improvement. it's easier to remember when things stick to existing conventions.17:00
niemeyerrog: Sorry, let's move on17:02
fwereade_rog, I'm about to poke at pstate with a view to possible removal anyway :)17:02
rogdo we have to use StartX for anything that invokes a goroutine?17:02
rogsorry, i'll stop17:02
niemeyerrog: When the next case shows up, we'll talk.17:02
hazmatjimbaker, sounds good17:03
jimbaker hazmat, cool, just invite jim.baker@canonical.com17:03
hazmathmm.. invites out17:03
hazmatniemeyer, fwereade_, rog meeting time?17:05
niemeyerhazmat: Already joining17:05
fwereade_hazmat, noone here, I'll try again17:06
wrtptotal failure17:29
wrtpniemeyer: i'm back online (on my apple, cos my laptop seems to have forgotten it can connect to a wireless network) and the hangout is full17:30
wrtpniemeyer, fwereade_, TheMue: so i guess you can tell me what went on :-)17:30
niemeyerwrtp: Oops :(17:30
wrtpniemeyer: i've no idea what's up with the laptop. it keeps on asking me for passwords (it should have them stored in the keyring) and doesn't connect anyway17:31
wrtpniemeyer: it's been funny all day in fact. rebooting didn't help.17:31
wrtpanyone got a handy hint for diagnosing ubuntu wireless connectivity problems?17:33
Aramyou use network manager?17:34
rogit seems to be working again, woo17:54
* robbiew had to bail18:02
hazmatniemeyer, fwiw.. no bugs i can see log of hooks/scheduler.py http://pastebin.ubuntu.com/854310/18:09
niemeyerhazmat: http://paste.ubuntu.com/854315/18:10
niemeyer111 looks like a fix18:10
niemeyer127 too18:11
niemeyer157 too18:12
hazmatniemeyer, what's that a log of?18:12
niemeyerhazmat: juju/hooks/18:12
hazmatniemeyer, that's quite a bit more than the scheduler we where speaking of18:13
niemeyerhazmat: If you touch just scheduler.py, you won't get anywhere close to cleaning things up in the way I was talking about18:13
niemeyerhazmat: scheduler.py is a very particular interface that only makes sense with everything else in there18:14
niemeyer202 is a fix too18:14
niemeyer286 also18:16
niemeyer312, 315, and 451..18:17
niemeyerYeah.. all of that is a side effect of a new code base being polished.. change the code base significantly, and these may not show up again, but others will..18:18
rogright guys, i'm off now18:22
rogsee ya tomorrow!18:22
niemeyerrog: Have a good evening18:23
rogniemeyer: and you18:23
hazmatniemeyer, its clear we where talking about two different things, risk from a change, vs rewriting an implementation18:23
niemeyerhazmat: risk from (...) rewriting an implementation18:24
niemeyerhazmat: This is a gut suggestion.. I wouldn't rewrite one of the trickiest parts of an application that is working two months before a release that is supposed to be rock solid18:26
niemeyerhazmat: Your take18:26
TheMueback again18:26
hazmatniemeyer, its not clear you have the context on the problem or the solution that's under consideration.. your just pointing out an entire package of code, saying its had so many fixes and its tricky, be careful and don't touch it, while your saying how a rewrite will simplify things.  yes change is a risk for stability, and in some cases not fixing a bug is the right call, but this is a fairly straight small forward change... and the change as i exampled i18:34
hazmats to a part of the code that has been fine since day one... effectively its fixing a bug in a completely different package by adding a feature to the correct place.18:34
niemeyerhazmat: We're talking across each other indeed..18:35
niemeyerhazmat: In the call, I pointed out what I'd like to do in Go, and you said it might be doable in Python too. I said it was a significant change for this point in time. That's what I'm talking about still.18:35
niemeyerhazmat: I'm not suggesting you don't fix a bug.18:36
niemeyerhazmat: In fact, I don't think I ever said anything close to "not fixing a bug is the right call".18:37
niemeyerIn this context, of course.. in some cases it is the right call, surely.18:37
hazmatniemeyer, yeah.. i'm not considering rewriting that package, just fixing the bug.. the only rewrite at this point that's worth considering is the relation ephermal node watches via  a backport of the pinger18:42
niemeyerhazmat: Phew.. we agree, after all :)18:42
TheMueniemeyer_: when can i expect the zookeeper fix? or is it just again a tag problem?19:32
niemeyer_TheMue: Tip is fixing, and the branch just has to be merged19:35
niemeyer_TheMue: I can do that right after the current meeting19:36
TheMueniemeyer_: great, thx19:36
niemeyer_TheMue: Submitting20:10
TheMueniemeyer_: wonderful, appreciate it20:10
niemeyer_TheMue: Done20:16
niemeyer_I'm heading out for some exercising.. probably back later20:29

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!