[00:31] umm.. https://bugs.launchpad.net/juju-core/+bug/1256053/comments/3 [00:31] i think we need to mark this critical https://bugs.launchpad.net/juju-core/+bug/1215579 [00:31] <_mup_> Bug #1215579: Address changes should be propagated to relations

[00:32] i'm working up a script to resolve it, but even transporting the script to all the units is a bit tedious without resorting to ansible and a juju inventory [00:48] posted a workaround to both, nevermind re critical.. [00:56] hazmat: createing a worker running on ecah machine agent that listens to netlink should be straight forward [00:56] what hook would it fire ? [00:57] davecheney, the user's issue isn't actually the one that bug [00:57] davecheney, the netlink this is pure optimization [00:57] davecheney, the actual issue is that juju doesn't update the relations per bug http://pad.lv/1215579 [00:58] davecheney, ie. you can have unit related to another service whose ip addrss changes. juju will pick up the address change. but the private-address of that unit in its relations (which juju set) will never be updated. [00:58] s/netlink this/netlink thing [00:59] davecheney, fwiw.. here's my workaround for folks today.. https://gist.github.com/kapilt/a61efcb4eaef9e685397 [01:00] hazmat: i'll get tanzanite to start working on that bug after the githib migration; likely early next week [01:00] wallyworld_, awesome, thanks [01:00] maybe even this week if we have bandwidth [01:00] hazmat: stuff like that, just ensure i know about it and we'll prioritise it [01:01] wallyworld_, will do. [01:01] * hazmat calls it a night [01:03] morning all [01:04] axw: morning [01:05] axw: i've got agreement to set up a test instance running mongo 2.7.1 to see if that hep with the mongo instability [01:05] well, mongo > 2.4.x [01:05] 2.7.1 is the latest [01:05] wallyworld_: cool [01:05] it's compiling now on the instance, will create a jenkins job [01:07] axw: cause one of the failures with replicaset tests i looked at yesterday - the mongo process just died for no reason and hence broke the test. there's several mongo bugs which might be culpable which are fixed in 2.6 or later which are not being back ported [01:07] so if this goes well, we'll look to get mongo 2.6/7 into juju-mongodb [01:08] wallyworld_: did it actually die (core?) or did it just drop the connection? [01:08] wallyworld_: meant to ask on the hangout, but forgot [01:08] axw: the log showed the mongo process itself died [01:08] ok [01:08] and the test tried to reset and ping and failed cause the process was gone [01:09] * wallyworld_ taps fingers waiting to mongo to finish compiling === revagomes_ is now known as revagomes [01:38] thumper: http://paste.ubuntu.com/7525844/ [01:38] what am I not seeing ? [01:39] davecheney: whitespace maybe? [01:40] davecheney: menn0 and I suggest doing a full print prior to the assert [01:40] just to check [01:41] err := st.users.Find(bson.D{ [01:41] {"_id", bson.RegEx{ [01:41] Pattern: "^" + regexp.QuoteMeta(name) + "$", [01:41] Options: "i", // case-insensitive [01:41] }}}).One(udoc) [01:41] if err == mgo.ErrNotFound { [01:41] err = errors.NotFoundf("user %q", name) [01:41] } [01:41] return err [01:41] } [01:41] sorry, ignore that [01:41] thumper: full print ? [01:42] davecheney: fmt.Printf("%q", tw.Log) [01:43] kk [01:48] hmm, that just makes things more confusing [01:48] * davecheney goes to look at js.LogMatches [01:52] grr [01:52] this is a bug with the matcher [01:52] http://paste.ubuntu.com/7525911/ [01:53] when times didn't match, the matcher returns false but keeps the reason to itself [02:26] has anyone tried to write a gocheck checker that checks the output of another checker [02:29] oh and the checker type is not exported [02:29] * davecheney throws a table [02:44] davecheney: gocheck.Not does that [02:47] axw: can I use that to write a test of a checker ? [02:48] davecheney: sorry maybe I misunderstood. I don't know how you'd do that [02:48] axw: s'ok, i'm working on something [04:13] if state/state.go has an un-exported logger, can I use that in state/action.go, or should I declare a new logger with a different name to avoid a name collision? [04:15] thumper: since it's midday likely for you, and you just emailed about errors... ^^^ :) [04:16] jcw4: you can use logger in any file in the same package [04:16] jcw4: all source files in the same package can/should use the same logger, as a general rule [04:16] so just use "logger.Debugf" in action.cog [04:16] jam1, axw great. Thanks [04:17] Is it expected that the output of add-machine is to Stderr? ex. "created machine 1" [04:26] axw: with the replicaset stuff - we cab back it out if it doesn't help, or, if 2.7.1 works better we can change it also, or william likes the idea of mocking out the replicaset behaviour and adding separate CI tests so we'll be looking into that as well [04:26] wallyworld_: sounds good [04:43] jimmiebtlr: I assume so... sorry. I don't know [04:47] I can't seem to get -gocheck.f="ActionSuite" [04:47] to work [04:47] is there a trick to it, or does it just not work? [04:49] jam1: ^^ :) [04:49] jcw4: you're sure it is spelled "ActionSuite" and not "actionSuite" or some other spelling? [04:50] jam1: interesting... yep, just verified [04:50] go test -gocheck.v -gocheck.f=apiclient does what I would expect [04:51] is it somehow related to not having the testing package initialize in that suite? [04:51] jcw4: are you trying to run the tests recursively? or just in one dir? [04:51] go test -gocheck.f="ActionSuite" ./state/... [04:51] jcw4: if you don't have a testing.T function in a package, then no tests get run by "go test" [04:51] jcw4: well, I'm sure that syntax won't work, because you are passing the "…" at the end [04:51] jcw4: which directory are you running "go test" from? [04:52] jam1: I see [04:52] and go test is a bit picky about argument order [04:52] menn0: juju-core [04:52] what is the preferred argument order jam1 [04:52] jcw4: at the least, you need to spell it "go test ./state/… -gocheck.f=ActionSuite" [04:52] jam1: Ah! I see [04:52] the issue is that there are some arguments that are processed by "go test" [04:52] try changing to the package directory where ActionSuite is defined [04:52] menn0: +1 [04:52] and there are other arguments that are processed by the binary that it builds and runs for you [04:53] "…" is telling *go test* to run everything [04:53] "-gocheck.f" is being passed to the binary that gets built to tell it what to run [04:53] I believe the -gocheck args don't get passed down if you run use "..." [04:53] since "go test" itself doesn't understand what "-gocheck" means, it stops processing arguments and hands the rest to the binary being run [04:53] davecheney: right? ^ [04:53] axw: it does, you just have to spell it right [04:54] axw, jam1, menn0 fantastic help. Thanks [04:54] axw: I originally thought it was all broken because "-gocheck.v" looks like it doesn't work, but actually it does, but without "-v" "go test" in recursive mode suppresess the output [04:54] so you have to do: [04:54] go test -v ./… -gocheck.v -gocheck.f=XXX [04:54] axw: ^^ [04:55] axw: and you can't quite do that in juju-core because the 3rd party packages under utils don't use gocheck, and thus fail if you try to pass them those flags [04:55] hmm ok [04:55] gocheck.v isn't doing anything when I use ... [04:55] what sucks, is that having the test binary passed positional arguments [04:55] doesn't fail [04:55] but it does fail if you pass named options [04:55] (ah consistency....) [04:55] axw, jam1, menn0 yep it worked (when I didn't use ..., and reordered gocheck opts to the end) [04:57] jam1: ah right, missed the need for -v [04:57] jcw4: axw correct [04:57] those arguments should go at the end of the command line [04:58] axw: yeah, so did I for a *long* time. [04:58] there is no reason gocheck couldn't adjust gocheck.v based on the test.v value which is better handled by the go tool [05:08] does anyone have experience with writing gocheck checkers ? [05:08] this is doing my head in [05:11] davecheney: I've done some [05:12] jam1: can you explain how the Check siganture works ? [05:12] Check(params []interface{}, names []string) (result bool, error string) [05:12] names appears unused [05:12] error is a string [05:12] if you are writing a checker, you should generally not put anything into error [05:12] result appears to indicate succes or failure [05:12] jam1: why not ? [05:12] because it indicates there is actually something you cannot test [05:13] davecheney: if you return an error it gets reported immediately, and breaks things like Not() [05:13] because Not(error) is still error [05:13] ok [05:13] while Not(resultFalse) is still true [05:13] this all started because [05:13] s/still/ [05:14] davecheney: so IIRC, names can be used as an output variable, but you don't have to do anything with it as input [05:14] http://paste.ubuntu.com/7525844/ [05:14] but names is passed as a value [05:14] there is no way I could append to names inside the function [05:14] and have that visible to the caller [05:16] davecheney: you may not be able to append, but I think you can change in place [05:16] true [05:16] ok [05:17] I believe that is how I made slightly nicer error messages by replacing params in place (so when you get an array of 100 things, you can report the 1 that is actually wrong, and hide the rest) [05:17] ok [05:18] that helps me understand what is going on [05:18] * jam1 really dislikes the in/out parameters, but that seems to be how gocheck works [05:18] go check is ok as an assertion framework, but writing checkers is ass backwards [05:18] I was trying to figure out how to give nicer errors, but I can't just return something into "error" because that is a forceful failure [05:19] davecheney: fwiw, I think the actual failure from your paste is that the LogLevel is wrong, but it isn't being shown [05:19] checked that [05:20] [{"INFO" "audit" "audit_test.go" ')' "2014-05-27 11:52:08.804353055 +1000 EST" "user-agnus: donut eaten, 7 donut(s) remain"}] [05:20] expected [05:20] obtained [05:20] ["INFO user-agnus: donut eaten, 7 donut(s) remain"] [05:20] ah, ffs, the match is a regex [05:20] and (s) doesn't match $s$ [05:20] if you excuse me [05:20] i have to go outside and shout [05:22] well, on the positive side [05:22] i've got a branch which improves the coverage of the LogMatches to 100% [05:22] * jam1 wonders if we should have a fallback "regex did not match, but exact match did" error message. [05:22] :) [05:36] axw, hey, re https://launchpad.net/bugs/1215579 [05:36] <_mup_> Bug #1215579: Address changes should be propagated to relations

[05:36] fwereade: yo [05:36] axw, please let me know what you're planning to do there [05:36] fwereade: just trying to figure it out right now... [05:36] fwereade: much bigger than I realised :) [05:36] axw, indeed, it's in a positive thicket of subtleties [05:37] fwereade: I was thinking a new worker, relationuniter, which watches for address changes on a machine and then updates the private-address setting for all relation units on that machine [05:37] axw, the main issues are: (1) we have to have a hook for it, otherwise units can't respond to their *own* changes of address [05:37] axw, -100 [05:38] axw, a worker that keeps an eye on address changes is one thing [05:38] axw, fucking around with relations outside the purview of the uniter will totally fuck us [05:38] ok [05:39] axw, one issue is that they use the much-maligned state.Settings, which is only safe for writes from a single client [05:39] axw, and that clientis the uniter [05:39] fwereade: yeah, I modified to do be safe in that regard [05:40] with a loop that checks for concurrent changes... but I hadn't considered units changing the address themselves [05:40] axw, but even if that were fixed, the units (1) have to know what their addresses are and (2) have to be able to reject private addresses they don't like [05:41] axw, and this only becomes more critical as we build up the networking model [05:41] axw, (re (2): proxy charms) [05:42] ok. I think I lack enough knowledge in this area that I'm going to be dangerous. I'm going to unassign myself for now [05:42] axw, well, it demands care and forethought, but I wasn't trying to actively scare you off... [05:42] I will keep looking at it, I just don't want anyone to get their hopes up :) [05:42] axw, remind me about what you did to settings? [05:43] niemeyer, morning, welcome to malta, sorry I haven't said hi before now [05:43] fwereade: Heya, thanks! [05:44] fwereade: nothing in the tree yet. I made a RelationUnit.UpdateSettings method; extracted the operation building from Settings.Write (into WriteOps), and had UpdateSettings do that with a assertUnchanged in a loop [05:44] should lbox propose should create a code review on rietveld? [05:45] jimmiebtlr: yes, that's its purpose [05:45] ok, I got the error "User does not have sufficient permissions to edit the bug task milestone." and no prompt for credentials for it [05:46] axw, ah, excellent -- there are other problems with settings, too, and if we can find an excuse to address them we should do so (because at last, with the db not exposed, we can do so sanely) [05:46] jimmiebtlr: try without -bug [05:46] ok [05:47] axw, are you free for a hangout in a few minutes? [05:47] fwereade: sure, let me just make a cup of tea [05:51] axw: That did it, thanks [05:53] jimmiebtlr: no worries. if you go to the bug, you can associate the branch manually (top right, "Link to a related branch") [05:53] fwereade: ready when you are, shall I start one? [05:54] axw, please [05:55] jimmiebtlr: how come your merge proposals don't have code review links ? [05:57] When I do propose with -bug set, it gives permissions error and never seems to make it to the rietveld creation [05:58] I think I have to first do it without setting bug, then go into launchpad and set it through the gui. [05:58] Sorry about the number of emails, trying to figure the tools out [06:17] fwereade: https://codereview.appspot.com/92630043/ -- updated to address your feedback [06:17] fwereade: should I lbox propose again, or wait til you've reviewed the code? [06:20] fwereade: I suppose I have to lbox propose again to pick up the newly edited changes... [06:20] jcw4, lbox propose again please [06:21] fwereade: incoming.... [06:27] * jcw4 is EOD... cya later === Ursinha-afk is now known as Ursinha [06:42] fwereade: I've put together a patch to change Login to accept and return EnvironTags, and to have those values saved in the cache and passed in on demand. [06:42] It does not do it with a v2 of the Login api [06:42] because I haven't gotten to the client side of that stuff yet, and because my other stuff hasn't landed anyway. [06:42] You're welcome to say "I only want this in a v2" and it goes into WIP until I can do it. [06:43] but I figure the code as it stands is reasonable to review. [06:44] jam1, cheers [06:49] fwereade: https://codereview.appspot.com/101760046 [06:51] jcw4, btw, if you have draft comments waiting when you lbox propose again, it will publish them alongside the PTAL message [06:56] fwereade: so the post is up, an email sent to the CI guys, and I'm off for about 2 hours to go be entertained by what my son is doing in school. bbiab [06:56] jam1, take care, have fun [08:14] morning all [08:15] voidspace, heyhey [08:33] fwereade: thanks for the review [08:34] fwereade: one other thing I wanted to run by you, while working on this, I discovered that only JujuConnSuite and cmd-restore use NewAPIConn, and I'd like to kill it with fire [08:34] it is the one that returns a Conn that has both a State and an Environ [08:34] but nobody actually needs that, and JujuConnSuite does bad things with it. [08:35] (JujuConnSuite.APIInfo() is implemented in terms of APIConn.Environ.StateInfo(), for examples of bad behavior) [08:46] jam1, awesome! has long been an ambition of mine, glad we're at the point we can do it [08:46] jam1, +100 [08:47] great, I thought you felt that way, and it got in the way of something I wanted to do :) [09:03] jam1, https://codereview.appspot.com/100460045/ LGTM [09:03] fwereade: thanks for getting to it, I know its a bit big [09:04] jam1, np; need to pop out for a while myself; would you take a look at casey's https://codereview.appspot.com/100400043/ if you get a moment please? I feel like I've lost perspective on it [09:04] k [09:33] fwereade: sorry, won't be able to chat about relation address things again today. Tomorrow hopefully, if that suits you [09:34] * axw bbl [09:34] so bzr blame says the code I'm interesting in was committed by Andrew in revision 2636 [09:34] but launchpad (juju-core) says that revision 2636 was by nate and doesn't contain this code [09:35] will bzr blame give the revision from the "original branch" rather than the revision it was merged onto trunk? [09:35] voidspace: are you sure it's not 2636.something.something? [09:35] mgz: it's 2636.4.2 [09:36] mgz: what does the 4.2 indicate? [09:37] mgz: "bzr help blame" says "revision, author and date" [09:37] okay, so then what you want is `bzr log -c mainline:2636.4.2` [09:37] mgz: ah, cool [09:37] mgz: thanks [09:37] that tells me what I need [09:37] the dotted revnos are changes off the mainline, (Andrew started from Nate's revision) [09:37] mgz: ah [09:39] now I need to see if I can find the original MP on launchpad, and any tickets closed as a result [09:39] but the commit message from "bzr log" has a link to the CL, which is handy [09:39] voidspace: should be linked from the... right [09:40] the CL has a link to the MP [09:40] gets me a step closer :-) [09:42] fwereade: I tested the "immutable syslog port" with local provider and it works fine [09:43] fwereade: running a test against a canonistack HA deployment before I merge, just for sanity [09:48] wallyworld_: ping, you still around? [10:03] heya all, anyone got any more details on LP #1307434 ? We're hitting the same issue using mgo in a different project [10:03] <_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout"

[10:08] voidspace: i'm here, but eating dinner, can ping you soon [10:11] jam: ping [10:11] rogpeppe: pong [10:11] wallyworld_: cool, thanks :-) [10:12] jam1: i was just looking at this https://codereview.appspot.com/101760046/ and a slightly different approach occurred to me, which i thought i might run by you [10:14] jam: because i've been thinking about multi-tenant state servers [10:15] jam1: specifically, i was wondering about, rather than specifying the environment in login, we could specify it in the URL for the API [10:15] so we could, but we don't currently connect to a URL in as many letters. The information we store is a host:port combination, which we turn into a URL [10:15] so yes, with a but [10:16] jam1: that means that *all* the URLs for an environment (including charm putting, logs, etc) can be accessed with respect to an environment [10:16] jam1: yeah, you'd need to know the environment uuid when you call api.Open [10:17] jam1: but you probably want that anyway (because nothing much calls Login explicitly) [10:17] which I am migrating towards, but all existing .jenv files, etc don't know the UUID [10:17] so I think at the least we still need to get that data into the files [10:18] jam1: you're migrating towards calling Login explicitly? [10:19] no, towards passing EnvironTag/UUID into api.Open via the api.Info struct === vladk|offline is now known as vladk [10:19] jam1: that sounds great [10:19] jam1: i guess the question is just what happens under the hood in api.Open [10:20] *today* it is easier to do it compatibly via Login, if only because I've already written that code :) [10:20] but also, changing all the URLs we use is going to involve a whole different layer (the HTTP mux) [10:21] jam1: yeah, it will (but it's work we do want to do some time anyway) [10:21] but I also think what I've done doesn't preclude us from doing that in the future. [10:21] jam1: i guess it doesn't matter if we pass the UUID in Login too [10:21] jam1: when the UUID is in the url, it will just be a tiny bit of extra validation [10:23] jam1: i guess if we're explicit that the UUID in Login is *only* for validation, not for selection, then we'll be ok for backward compatibility too [10:25] jam1: BTW, do we now generate the UUID and store it in the .jenv file at bootstrap time? [10:25] not yet [10:27] voidspace: back now. late dinner tonight after soccer. what can i do you for? [10:30] wallyworld_: hi! [10:30] heya [10:30] wallyworld_: hey [10:30] wallyworld_: so I'd like to re-enable mongo replica sets for local provider [10:30] great :-) [10:31] wallyworld_: apparently there was a problem with them previously, which I'm led to believe you reported [10:31] i can test since it broke for me [10:31] wallyworld_: I'm struggling to find the issue though [10:31] but [10:31] we obviously need to work out why it was broken for you and fix it [10:31] i upgraded my kernel today and that broke cgroups and hence local :-( [10:31] hah [10:31] i'll need to downgrade [10:32] ouch [10:32] it broke for me because mongo just didn't start [10:32] can't recall the exact error [10:32] but the upstart job failed to start mongo with --repl or whatever the ption was [10:33] but i can just test it again to see if it works [10:33] i think one other person also had the issue [10:33] not sure who now [10:34] wallyworld_: ok, thanks [10:35] voidspace: i can do that tomorrow after i downgrade my kernel, is that ok? [10:35] wallyworld_: I'll create a branch with HA always on (just delete the code that switches it off) and you can try it [10:35] wallyworld_: tomorrow is fine, thanks [10:35] i have some other stuff i need to try and get done tonight [10:35] cool [10:35] i'll let you know how i go === vladk is now known as vladk|offline [10:38] wallyworld_: I'll push a branch and email you a link [10:39] wallyworld_: tomorrow is fine [10:39] ok [10:39] ta === Ursinha is now known as Ursinha-afk [10:49] jam1, fwereade, standup? === vladk|offline is now known as vladk [10:50] dimitern: sorry about that, brt [10:51] hello [10:51] need a reboot, brb [10:52] dimitern, with you in a mo [10:52] dimitern, don't wait [10:54] mgz: how's the github stuff? did you get to talk to rick or you don't need to now? [10:55] wallyworld_: I didn't need anything from him yesterday, will probably bug both him and curtis today about the remaining small things [10:55] ok [10:56] mgz: if you talk to curtis make sure he is ok with the timeframe or else we'll need to delay [10:56] yeah [11:00] mgz: you on track to get the contributing doc finished up today (with everything else you have to do)? [11:00] yup [11:00] great :-) [11:00] thanks for the comments from you and andrew [11:00] np, hope they helped [11:01] i'd like to email it out soon so will do so when you finalise it [11:05] morning === vladk is now known as vladk|offline === vladk|offline is now known as vladk [11:09] perrito666: morning [11:09] perrito666: morning [11:09] wwitzel3: morning === Ursinha-afk is now known as Ursinha [11:47] fwereade, jam1, vladk - the goamz branch I'd love a review on https://codereview.appspot.com/100780048 === vladk is now known as vladk|offline === vladk|offline is now known as vladk [12:08] right, lunch time [12:08] * voidspace lurches [12:09] voidspace: uh, thats true, medicine time, bbl [12:24] jam1, replied to bug instead of you, sorry === TheMue is now known as TheMue_AFK [12:27] niemeyer, hey [12:27] dimitern: Heya [12:27] niemeyer, I have another small goamz branch, if you can take a look https://codereview.appspot.com/100780048 [12:28] fwereade: When are you coming? [12:28] dimitern: Cool [12:28] niemeyer, heh, haven't really figured it out yet -- I was thinking mid-afternoon on wed, thu, or fri would be pretty convenient, though, because I can get a lift most of the way there [12:29] niemeyer, do you have something particular in mind that I should be at? [12:29] niemeyer, because, you know, there's nothing stopping me at any other time [12:29] niemeyer, (well, I have a washing machine being delivered in a couple of hours, so today ain't great, but still) [12:30] fwereade: Nope, nothing specific.. might just be nice to take the chance that 100+ co-workers are around to interact a bit [12:31] niemeyer, yeah, I just don't want to show up and end up hanging around being useless ;) [12:32] niemeyer, I'd been thinking at least that I could come down and see some people in the evening one (more?) of those days [12:32] niemeyer: well you are trying to make a geek choose between a new gadget and 100+ people... that is unfair [12:32] niemeyer, how are your plans looking? [12:32] fwereade: I would take the chance to be here most of the time, to be honest, even if you're just working on your usual tasks during meetings [12:33] fwereade: There's open space to hack, and just being around to talk to people over breaks is worth it [12:33] fwereade: That's how I would feel if people would so close to me, either way.. :) [12:33] s/would so/were so/ [12:34] niemeyer, that's very true, I guess I'd kinda assumed that hacking space might not be so available [12:38] mgz, re gh please don't transfer history how gui did it (squashing branch commits into mainline history) [12:39] hazmat: yeah, we'll keep all the commits, even though git doesn't handle them quite as neatly [12:40] mgz, well more to the point.. goal would be not polluting main branch history with every branch's individual commit as linear line. [12:41] which is what gui ended up doing [12:41] hazmat: ...that sounds like the opposite of what I understood your first comment as [12:42] mgz, squashing was a bad word choice, s/polluting would have been better [12:43] mgz, ie. doing a git log on trunk should see merge commit messages, not every branches individual commit messages.l [12:43] hazmat: it may be something to raise on the mailing list then, the current planned import does no squashing [12:46] mgz, hmm.. actually i think i might be off track here.. git log --oneline --graph shows what i would expect, just the default git log shows minor commits on feature branches by default [12:46] yeah.. git log --oneline --first-parent is the equivalent of bzr log [12:46] er. bzr log --line [12:47] yeah, it's an issue with the git tooling [12:47] git itself does the dag okay [12:56] dimitern: https://codereview.appspot.com/100780048/ reviewed [12:57] mgz: just that most git tools think first parent isn't relevant and sort by sha1 for ordering rather than the actual recorded merge parent ordering. [13:09] jam, thanks! === vladk is now known as vladk|offline [13:36] niemeyer, I've updated the branch after fwereade and jam reviewed it, I just need your review :) https://codereview.appspot.com/100780048/ [13:37] dimitern: Okay, I cannot promise to be timely there [13:37] niemeyer, ok, when you can, thanks [13:38] dimitern: Or just go ahead and merge it.. I trust John and William [13:41] niemeyer, thanks! [13:42] niemeyer, it's just for testing, no public-facing logic has changed [13:43] dimitern: Super, thank you [13:45] dimitern: I think you can simplify the "known" changes if you go back to a bool map. [13:45] since you can just do && idMap[id] [13:45] sort of stuff [13:45] welcome gsamfira ! [13:46] hey alexisb :) [13:46] jam, oh, sorry I forgot about this [13:47] jam, but I'll fix it next time i need to make changes, it's not a big deal [13:54]