[08:56] Mornings [08:56] heya niemeyer [08:58] niemeyer, fwereade_: yo! [08:58] niemeyer, you're up early :) [08:59] fwereade_, rog: Yos! [09:00] fwereade_: Yeah, a bit earlier than usual today [09:25] morning gustavo [09:25] TheMue: hey hey! [09:26] TheMue: Welcome! :-) [09:26] niemeyer: thx [09:26] niemeyer: sadly i have no access to our wiki [09:26] TheMue: That happens.. you should get it soon [09:26] niemeyer: so i read the public stuff [09:27] TheMue: Are your details being sorted out already? [09:27] TheMue: All of the data for the project is public [09:29] niemeyer: I've got my launchpad account working and the login to the wiki is granted [09:29] TheMue: That's cool [09:29] niemeyer: but then I've got no right to read something [09:30] TheMue: Hm? [09:30] niemeyer: here i am => https://launchpad.net/~themue [09:31] TheMue: Ok? [09:50] hmm, forgot to group the consts in the same declaration :/ [09:50] someday gofmt will be smart enough to do even that for me hehe :) [09:52] gofmt in chuck norris mode would analyze the semantics of your project, optimize the code and add speaking comments for godoc. :D [10:01] uh weird, I've just received a mail saying that: "Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal. It was logged with id OOPS-3635c3dab3398e5564a4a31dc006dd36. Sorry for the inconvenience." [10:23] niemeyer: hmm, got an error when trying to repropose [10:23] 2011/12/01 11:22:20 RIETVELD Failed to prepare request: computing base hashes: command [bzr cat -r revid:roger.peppe@canonical.com-20111116163854-05vsxizrv13b83r8 juju/Makefile] failed: exit status 3 [10:23] 2011/12/01 11:22:20 RIETVELD Response from server: Issue creation errors: {'base': [u'Base URL is required.'], 'subject': [u'This field is required.']} [10:25] mpl: Try to execute the bzr cat command locally and see what's the output [10:25] TheMue: Do you have the list of tasks to go over yet? [10:27] niemeyer: Sarah passed me a starting point for day 1. [10:27] TheMue: COol [10:27] niemeyer: ok, found the problem. apparently I'm supposed to issue the command from the root of the repo. I was inside "juju", so the bzr cat command couldn't find juju/Makefile. [10:27] thx [10:27] mpl: Oh, interesting [10:27] mpl: I should fix that in lbox [10:28] that would be nice, yes. [10:28] niemeyer: in parallel i'm reading the docs and look around the issues in florence (nice tool) [10:28] niemeyer: want me to file a bug report or something about that? [10:28] mpl: Yes, please! [10:29] niemeyer: k, will do. [10:30] mpl: Thanks! [10:30] sure. [10:36] <_mup_> juju/go r20 committed by gustavo@niemeyer.net [10:36] <_mup_> Merged juju-go-log branch from Mathieu Lonjaret. [r=niemeyer] [10:36] <_mup_> This branch adds support for logging into the juju package. [10:36] <_mup_> Logic in this package and in its subpackages should now call [10:36] <_mup_> juju.Logf or juju.Debugf to generate useful information about [10:36] <_mup_> what's happening. [10:56] mpl: Would you mind to explore the idea of making Debug and Logger as global variables in another branch, as rog suggested? [10:59] niemeyer: sure [11:23] mpl: Cheers! [11:27] niemeyer: just for info, my launchpad profile is added to the canonical group and my access to the wiki does work now [11:37] TheMue: Superb [11:37] TheMue: But again, it doesn't matter much as far as juju goes [11:37] TheMue: It's all in the open [11:37] TheMue: You'll find some good details about how the company works, etc, there, though [11:38] niemeyer: Yep, that's what I want to know today. First the organization to see what's important here for me, and then juju. You'll then get a lot of questions. *smile* [11:39] niemeyer: I hope the source code is well commented to get the semantics. [11:46] niemeyer: Setting up internal irc and mail now, those tasks. [11:50] TheMue: hi and welcome! [11:51] rog: hi and thx, now i'm on board too [11:51] TheMue: cool [11:54] another colleague interested in go here in germany also starts today. but he's working in a different team [11:54] TheMue: Got hired by Canonical? [11:54] mainerror: yep [11:54] Nice! [11:54] Congratulations. [11:56] TheMue: That sounds great [11:56] TheMue: Just let me know when you're ready to rock [11:59] mainerror: thx [11:59] You mentioned go. Go as in Go the programming language? [12:00] niemeyer: you'll realize it with my questions. *smile* [12:00] mainerror: exactly [12:00] Cool. [12:01] btw, anybody visiting the oop 2012 in january in munich? i've got two talks there. one about go and the app engine, one (a pecha kucha) about concurrency as a 'natural' paradigm [12:02] niemeyer: when we're talking about stripping down go-juju-initial-ec2, how bare should it go. shall i keep it so it can still talk to ec2 (without the extraneous logic) or should i should i strip it to really bare bones, so there's almost nothing there apart from the structure? [12:02] s/should it go./should it go?/ [12:02] rog: The latter [12:03] TheMue: When in January? It wouldn't be that far for me but the date might collide with my visit to Budapest. [12:03] rog: Then, try to go the TDD route, introducing new logic with tests [12:03] mainerror: end of jan, i'm in budapest too. [12:03] niemeyer: so copy dummyProvider from juju for an initial step? [12:03] Oh I see. [12:03] rog: By migrating from the previous branch chunk by chunk, and submitting for review once you're happy with a first delta [12:04] rog: That sounds reasonable [12:04] Well then chances are good that we meet each other twice. :) [12:04] +# [12:04] s/+#// [12:14] niemeyer: should I make it a different package as well, as rog is suggesting? (I'm not sure your "and I'm happy with that." means you want me to go for it). [12:36] mpl: Yes, thanks a lot for pursuing that [12:45] so, changed the configuration [12:47] niemeyer: hmm, I'm still struggling with bzr. I thought that since you merged, I should see rev 20 on https://launchpad.net/juju/go, or when doing a bzr pull from the lp:juju/go branch I have. what am I missing? [12:58] mpl: from looking at this page, it looks like it hasn't been merged yet: https://code.launchpad.net/~mathieu-lonjaret/juju/juju-go-log/+merge/84074 [13:08] rog: hmm, and yet the _mup_ bot pasted a few lines above stating it had been merged. [13:08] mpl: good point. i don't know what's going on there. maybe there's a delay [13:09] or I could simply keep on working from this not yet merged branch I suppose... [13:25] mpl: i'd do that [13:25] niemeyer: is this more the kind of thing you had in mind? https://codereview.appspot.com/5432056/ [13:26] rog: This patch set seems to include changes from the other branch you pushed [13:27] niemeyer: if you look at the files, there's nothing in them. i think that lbox hasn't deleted them from the codereview page [13:28] rog: https://codereview.appspot.com/5432056/diff/1019/juju/dummyprovider_test.go [13:28] niemeyer: and funnily enough, there are files that *should* be there (the jujutest package) [13:28] rog: Check your patch locally.. lbox simply sends what it finds [13:29] hmm, i thought i branched from the most recent trunk [13:29] so many branches! [13:30] niemeyer: bzr ls shows the jujutest directory. [13:30] rog: The diff [13:30] niemeyer: i think i'll just create a new merge request [13:30] rog: it'll do you no good [13:30] rog: It will send the same diff [13:31] http://paste.ubuntu.com/755994/ [13:32] jujutest is in there, but not on the codereview page [13:32] rog: How did you generate that diff? [13:32] niemeyer: cd go-juju-initial-ec2; bzr diff -r ../go-trunk [13:32] is that wrong? [13:32] rog: bzr diff -r ancestor:../go-trunk [13:34] niemeyer: hmm. what's the difference? [13:34] rog: This will diff your branch against the merge base [13:35] rog: Which means it's generally the true changeset that will be applied when you actually bzr merge [13:35] niemeyer: i don't understand. what's the difference between trunk tip and the merge base? [13:35] rog: and it's what lbox uses to send to codereview [13:35] rog: Maybe none, maybe there is [13:35] rog: It's none if nothing was committed in tip [13:35] niemeyer: so in this case, i've added a new directory and files in it, but it's not showing up. what am i doing wrong? [13:35] rog: Either way, is the diff the same or not? [13:36] no it's not. it's very different [13:36] rog: Cool, ok.. let me explain then [13:36] http://paste.ubuntu.com/755999/ [13:36] rog: Let's call tip T, and you had a branch B1 [13:37] (and i've just freshly branched go-trunk too) [13:37] rog: We debated about B1, and in the end some changes were forked off onto B2 [13:37] rog: But to generate B2, you actually *took* B1, and *removed* stuff from it [13:38] rog: Then, B2 got merged on T [13:38] yup, that's exactly what i've done [13:38] (i didn't remove anything from B1 that was in T though) [13:38] rog: Now, you're checking what would happen if you merged B1 into T [13:38] B2, no? [13:38] B1.. B2 was already merged, no? [13:39] i don't... think... so [13:40] merge go-juju-machine-to-instance [13:40] revno: 19 [merge] [13:40] Where was this taken from? [13:40] * niemeyer looks at the branch history [13:40] ok, i think i did a merge then removed stuff [13:41] not realising that it might make a difference [13:42] rog: Yes, that was the case indeed: http://paste.ubuntu.com/756003/ [13:42] i'm still confused. why are the changes that i've made since being ignored? [13:42] rog: So now you're trying to merge the original changes, but you already have _new_ history demonstrating that your latest interest is to remove that stuff [13:43] rog: So bzr looks at history and says "Oh, hey, I already merged those revisions.. all good!" [13:43] because the trunk counts as newer than my current branch? [13:43] rog: They haven't been ignored.. on the contrary... they've already been merged [13:43] but i've put them back again! [13:43] rog: That's the point, you haven't [13:43] rog: The revision you have locally is exactly the same revision that bzr has in trunk [13:44] how can i put them back again then? [13:45] perhaps if i just do branch from trunk, cp -r and bzr add, that'll work? [13:45] rog: You'll have to redo it, effectively creating a new revision [13:45] rog: That'd be a *MAJOR* disaster :-) [13:45] rog: Never, ever, do that [13:45] oh? [13:45] rog: You're effectively killing everybody else's changes [13:46] rog: We can't ever assume we know the latest state of trunk [13:46] rog: The proper way now is this: [13:46] rog: branch from trunk again onto a new branch [13:47] rog: Apply the diff you really want to see happening onto this new branch [13:47] rog: (with patch, etc) [13:47] rog: and propose that one [13:47] ok, patch rather than cp -r, of course [13:48] rog: This is a new changeset, so you're effectively reverting the revert :D [13:48] same basic idea though - make local file changes rather than merging [13:49] rog: Yeah, basically teach bzr that you've changed your mind once more [13:49] niemeyer: yeah, i didn't know that there were any bad implications from doing that [13:49] niemeyer: i will never back-merge again [13:49] rog: Not a problem.. common gotcha of revision control [13:49] patch is my friend [13:49] if i can remember how to use it [13:49] -p0 ? [13:49] rog: You just have to remember that history matters [13:50] rog: Did A commit rev1, undo A commit rev2, merge both.. Trying to merge rev1 again does nothing. [13:50] niemeyer: that surprises me [13:50] (well, not any more) [13:51] rog: That's DVCS 101.. hg, git, bzr, bitkeeper.. [13:51] rog: and yes, it surprised people often [13:51] surprises [13:51] i'd assumed that in the absence of other merges, A+B-B+B == A+B [13:51] niemeyer, hazmat: what situation would cause a unit settings node to be deleted and recreated? [13:52] rog: And that's what happens.. but that's not what was done.. [13:52] but in fact A+B-B+B == A [13:52] rog: What you did was A + B + A, which is A + B [13:52] where A+B means merge(A, B) [13:53] rog: You never did -B, btw.. there's no such a thing as removing a revision [13:54] rog: You added C with a reverting patch [13:54] niemeyer, hazmat: because I can't see such a case, but there's a test which induces it, and if it's a realistic possibility (without the unit node itself being deleted) then I need to rethink things [13:55] well, ok. trunk + {add foo} + {remove foo} + {add foo} == trunk [13:55] fwereade_: Can you please paste the test? [13:55] where { } is a delta [13:55] niemeyer, just grabbing an unmodified version [13:55] rog: Again, that's not what you did.. [13:55] rog: You never re-added foo [13:56] rog: You expected that your foo from the first action would be there, despite it being removed in a latter revision [13:56] rog: What you're doing _now_ is re-adding foo [13:56] niemeyer: how is "bzr add foo" not adding foo? [13:57] niemeyer, as it says in the test, some "unforseen mechanism" [13:57] http://paste.ubuntu.com/756017/ [13:57] rog: You never re-added it.. [13:57] rog: Well, let me pick the history to make sure [13:58] niemeyer: so "bzr add" doesn't count as an add? [13:58] niemeyer: that's what confused me, i think [13:58] rog: You're being disingenuous now [13:58] niemeyer: no, that's the central difficulty i have. [13:58] niemeyer: it's not something I'd really worry about normally, but the existence of this test has made me all nervous ;) [13:59] niemeyer: that "bzr add" doesn't necessarily add the file when the revision comes to be merged. [13:59] rog: If you add the same file 10 times in the same revision it's of course a NOOP [14:00] niemeyer: but in this revision, i added it only once. [14:00] rog: The detail is that you never acknowledged the fact that the file had been _removed_ and then _readded_ it [14:00] rog: Exactly.. and it's still there, right? [14:00] rog: Now you're doing "bzr add" on it again.. and bzr is saying.. yep.. still there! [14:00] rog: Because you never merged the part of history that says "this file is being removed" [14:00] rog: History matters [14:01] rog: If you merge trunk onto your ec2 initial branch.. the file will be *gone* [14:01] rog: _then_ you can readd [14:02] rog: Have you ever read about vector clocks? [14:02] niemeyer: didn't go-juju-machine-to-instance (merged) have the removal history in? [14:03] rog: It does [14:03] niemeyer: yes, but i never fully got my head around them. or VCS. [14:03] rog: Ok [14:03] rog: Not a good analogy then [14:04] fwereade_: It makes sense to me [14:04] fwereade_: The point is precisely that a settings node being removed shouldn't cause a related unit to think that the configuration for the other side of the relation has changed [14:05] niemeyer, the test makes sense in its own narrow context [14:05] fwereade_: It's likely dying instead [14:06] niemeyer, however, if the mechanism it uses to verify that property is a realistic one, it means that settings node versions are not a reliable indicator of anything [14:06] fwereade_, nothing comes to mind [14:06] niemeyer: actually, the vector clock thing does make sense. i think you're saying that the changes to re-add the file come further back in vector "time" than my changes to remove the file. [14:06] fwereade_, the only thing that should be deleting a settings node is the teardown of a test [14:07] anyway, i'll just patch [14:07] rog: Precisely! [14:07] fwereade_, btw. one other point on the restart, if its a container restart, we do want to fire the start hook.. [14:07] hazmat, fwereade_: The removal/cleanup of a unit can delete a settings node.. [14:07] hazmat, fwereade_: The logic to ignore the removal of the node continues to make sense to me. [14:08] niemeyer: all I'm worrying about is settings node deletion *without* the unit being deleted [14:08] niemeyer: there's no problem with that test [14:09] niemeyer: I'm just checking that it's purely an artificial and unrealistic manipulation of ZK without known analogue in normal operation [14:09] fwereade_: I don't think we ever desired to support something like that consciously, at least, and I'm fine to say we don't [14:09] fwereade_, when you say settings you don't mean relation settings, which path are you referencing? [14:09] niemeyer: cool, thanks [14:09] fwereade_: Again, there is a relevant analogous [14:10] fwereade_: To precisely that test [14:10] fwereade_: It's not unrealistic at all [14:11] niemeyer: ok, sorry, I missed an important bit [14:11] niemeyer: deletion, fine [14:11] niemeyer: *recreation*, not fine [14:11] fwereade_: Fine as well! [14:11] niemeyer: right, got it. i think. [14:11] niemeyer: hmm :( [14:12] fwereade_: The relation with the unit on the other side may be reestablished [14:12] niemeyer, how? [14:12] fwereade_: In which case the settings node should be observed again [14:12] either the unit was removed or the relation broken [14:12] in either case the identity is different when restablished [14:12] hazmat: Why? [14:13] hazmat: Well, the identity of what is a better first question [14:13] of either the unit or the relation would have changed [14:13] which leads to a different settings path [14:13] hazmat: Huh? [14:13] hazmat: remove-relation a b; add-relation a b [14:13] ? [14:13] niemeyer, its a different relation identity the second time [14:14] hazmat: I see, ok [14:15] we do preserve unit settings in a relation post its removal, relying on ephemeral presence nodes for observation of membership [14:15] the test is going against a pathologic case [14:15] hazmat: It's not pathologic.. the fact we keep data around forever shouldn't be trusted [14:16] niemeyer, agreed [14:16] fwereade_: So, the behavior there looks good in terms of being resilient.. is there a reason why you'd like to not support that specifically? [14:16] a garbage collector processing live relations, should not trigger an observation change [14:16] when taking out the garbage [14:17] fwereade_, so recreation of the path is not a scenario [14:17] niemeyer, https://bugs.launchpad.net/juju/+bug/773600 points out that we'll need to pay attention to the settings node's versions to determine whether changes happened when the agent prcess was down [14:17] <_mup_> Bug #773600: Hook scheduler should have on disk persistence < https://launchpad.net/bugs/773600 > [14:17] of the settings that is [14:18] niemeyer: *if* recreation of the settings node is plausible (which I think, as hazmat says, it isn't), node versioning is not up to the job [14:18] niemeyer: because the version gets reset to 0 on recreate [14:18] fwereade_: Aha, that makes the matter a lot more clear.. [14:18] * niemeyer thinks [14:18] fwereade_, right, because we need to reconcile any change while disoconnected with the live state [14:19] hazmat: yep [14:19] fwereade_, so just to be clear, there is no normal scenario that allow for a recreate of the unit rel settings node [14:20] fwereade_: It feels fine for us to state that we never remove a unit's settings node in a given relation for as long as the unit itself is alive, at least [14:20] since we manage relations on a service level, the removal implies either the unit was removed, or the relation was removed [14:20] and attempts to resurrect would imply either a new unit identity or new relation identity at a different path [14:20] niemeyer, hazmat: cool, that all makes sense to me :) [14:20] thanks :) [14:20] fwereade_: Sorry for the confusion.. I guided the conversation to the wrong path not understanding your context [14:21] niemeyer: sorry, I could have been a lot clearer :( [14:21] niemeyer, not to worry :) [14:23] so the test is a pathlogical case if its recreating the node [14:24] hazmat: Ok, agreed [14:29] niemeyer: finally! https://codereview.appspot.com/5432056 [14:29] niemeyer: sorry for my obtuseness [14:31] rog: Woohay! [14:32] rog: Not worries at all [14:32] rog: I'm happy we've had that conversation.. you'll surely pass through similar circumstances [14:40] how does one specify the machine size in a charm? i can't find that in the docs. [14:42] i.e. for ec2 the default seems to be t1.small. for a redis server i'd like to bump it up. [14:47] SpamapS, made some progress tracking down the precise builds [14:47] SpamapS, i realize we can drop python-argparse as a dep for any release with py2.7 and it will remove this error [14:49] niemeyer: when trying to pull lp:~mathieu-lonjaret/juju/juju-go-log, I'm getting that error: "bzr: ERROR: These branches have diverged. Use the missing command to see how." and bzr missing doesn't give me much of a clue, sorry. [14:49] its a pkg_resources import causing a warning on stderr, which juju thinks is a process error [14:49] its early enough (import time) that the log machinery hasn't been setup yet to go to disk [14:50] mpl, bzr merge the upstream should resolve it [14:50] mpl, it implies that both branches have commits that aren't on the other side afaicr [14:51] mpl: Why are you trying to pull it? [14:51] mpl: You need a new branch now [14:51] niemeyer: because I don't have it anymore, I had removed it when I thought you had merged it. [14:52] mpl: I did! [14:52] mpl: Just update your trunk, and create a new branch from it [14:52] mpl: "bzr pull" on trunk [14:52] niemeyer: well, as I said above, it doesn't show on https://code.launchpad.net/~mathieu-lonjaret/juju/juju-go-log/+merge/84074 [14:52] mpl: Then follow the blog post on lbox again [14:52] mpl: Naming it differently [14:52] niemeyer: and bzr pull doesn't give me the rev 20 [14:53] mpl: Maybe I screwed up then [14:53] mpl: Hold on [14:53] niemeyer: the bot said you had merged. but nothing else seem to agree with that. :) [14:53] from my pov of course [14:53] mpl: The bot is optimistic indeed [14:53] haha [14:53] mpl: Yeah, it was my fault [14:53] mpl: Just pushed the change [14:54] mpl: Sorry about that [14:54] cool, thx. new branch it then. [14:54] no worries. [14:54] *it is then [14:54] rog: Reviewed ec2test [14:54] rog: Good work there man [14:55] niemeyer: phew. i thought i might need a boatload of tests for the testing code. (i thought that was going a little too far, and there are *some* tests!) [14:56] niemeyer: thanks BTW [14:56] rog: Yeah, testing the testing code would be a little too much.. :-D [14:57] I heard you like test code so I ... [14:57] rog: Firing goamz itself against it should be good enough [14:57] rog: But who tests the tests tests! OMG! [14:57] indeed [14:58] niemeyer: i will end up running more ec2 tests against it as functionality gets more complete [14:58] niemeyer: oh such a pleasure to use codereview again! [14:59] rog: +1! [14:59] niemeyer: BTW can you think of any way of avoiding the duplicate emails? [14:59] rog: That's been bothering me a bit too.. I don't have a good answer yet [15:00] niemeyer: filters aren't that clever either:-) [15:00] rog: It would actually be possible to filter out, but I'm concerned we might lose real changes that happen on the MP side [15:00] MP? [15:01] rog: merge proposal [15:02] hmm, maybe the trick is to avoid the codereview emails [15:02] ah, dammit [15:02] no [15:03] Ok, past lunch time here.. bbl [15:10] hazmat: I wonder if thats a bug in the python-argparse package [15:14] SpamapS, well its actually a pkg_resources thing.. py2.7 has argparse builtin, and we also have it as a package dep [15:15] and pkg_resources basically flags a warning that we're shadowing a builtin package [15:15] and because that happens so early on, it goes to stderr instead of the log file [15:15] hazmat: thats what I mean.. should the package even exist if it causes problems for pkg_resources ? [15:15] SpamapS: fixes in statusnet. [15:15] SpamapS: we're promulgating that today, I can FEEL it! [15:16] SpamapS, its not a fatal error, juju interprets it as such even though the process exits normally [15:17] we could be more discriminating about that, but right now it it interprets regardless of the exit code any stderr output of the launched unit agent as a failure since it should go to a log file per normal operations [15:17] jcastro: yeah, it was close yesterday. :) [15:17] \o/ [15:18] is there a way to specify the machine size for EC2 instances? [15:19] zirpu: You can do it in the environments.yaml file [15:19] http://askubuntu.com/questions/52021/how-do-i-adjust-the-instance-size-that-juju-uses [15:19] cool. thanks! [15:20] jcastro: indeed, looks good, I'll promulgate, you fire up the T-shirt cannon for the party [15:20] SpamapS: aka. "haha you have to test and blog this" [15:20] Keep that t-shirt cannon warm, I think phpMyAdmin is almost ready :P [15:20] SpamapS: when you're looking for a nice friday later afternoon hack make it so promulgate makes the bot go "Ding! New charm!" or something [15:21] marcoceppi: you can't specify machine size in a charm? only the global environments.yaml? [15:21] jcastro: Dude, the bot's written in erlang, my mind was nearly blown when trying to add questions to the feed [15:22] zirpu: Not that I'm aware of, there's a spec to have deploy specify machine size, but it's not implemented [15:22] ah. ok. thanks. [15:23] robbiew, ping [15:23] fwereade_: hey...there you are [15:23] wasn't looking for the "_" :/ [15:23] zirpu: indeed, its #2 on the priority list [15:23] robbiew, sorry, was afk, my brain melted down and I needed a coffee [15:23] fwereade_: lol, no worries...got time for a catchup g+? [15:24] robbiew, sure [15:24] one sec...will shoot out invite [15:34] niemeyer: hmm, the target has changed because of ec2 rename. should i continue with the old target (~gniemeyer) or make a new CL? [15:36] jcastro: done [15:36] * SpamapS wishes we had an audit log of promulgates [15:36] nice! Ok congrats everyone, there's one more charm! [15:36] pretty cool charm actually [15:38] oi.. teamspeak3 charm is new as well [15:42] SpamapS: ... and working awesome for me [15:42] man, the speed from 0 to "out there" never gets old [15:45] rog: hmm, are you automatically notified of everything I lbox propose, or should I somehow add you as a reviewer in codereview when you're concerned? [15:46] s/hmm, // :) [15:49] mpl, people generally get emails about it if they subscribe to the repo the merge is being proposed to [15:52] hazmat: thx. I suppose that means yes in the case of rog :) [15:53] mpl, well assumptions are dangerous.. but i've been seeing your merge proposals ;-).. good stuff [15:55] hazmat: btw, thanks for looking into the argparse thing. So did you push a fix up, or you just think you might have one? [15:55] hazmat: well, it's all pretty simple and preworked for me by gustavo, so I can't take much credit there. but thx. :) [16:07] niemeyer, hazmat: concurrent callbacks in RelationUnitWatcherBase: I don't quite understand how they can be safe, even if they are on changes to different nodes [16:07] niemeyer, hazmat: HookScheduler.notify_change doesn't look to me like it will handle them correctly [16:08] niemeyer, hazmat: I presume I'm missing something..? [16:08] fwereade_, why not re the latter, that's how the changes are serialized into an event stream, the hook executor itself is the one that does the serialization off the ordered stream from the scheuduler [16:09] fwereade_, i guess i'm not understanding the question.. how are they not safe? [16:09] hazmat: ...ah, ok, notify_change doesn't yield [16:09] fwereade_, yup.. its definitely synchronous [16:09]