[00:57] jimbaker, you can do the encode/decode on the server [00:57] jimbaker, the transport is irrelevant to maintaining the format [00:58] ie transfer in yaml, encode/decode cycle in json [03:07] hazmat, i will see if i can make that work [03:07] hazmat, in principle this makes sense, it just is the approach i first tried. however, the code is much more refactored, so it's possible this is simpler to do [06:06] morning davecheney [06:15] fwereade: howdy [06:16] davecheney, how's it going? [06:18] fwereade: good; so we're back to lisbon in july i hear [06:18] davecheney, yeah, that's my understanding [06:18] davecheney, is that better or worse for you? [06:19] fwereade: probably better, although I dunno if mark will like the prices, 2700 euro [06:19] well, between 2000 and 2700 [06:19] davecheney, cool -- and, well, the cheapest I saw for me to POA was >2000 euros [06:19] that is what i decoded from the travel agent blather [06:19] fwereade: it was more the 45 hours travel that didn't do it for me [06:20] * fwereade winces *hard* [06:20] i think it went SYD -> the frikken moon -> POA [06:20] davecheney, haha [06:20] then a return trip via saturn [06:20] which is insane, because it's shorter to go SYD -> Perth -> POA, than SYD -> LAX [06:20] geographically speaking [06:21] davecheney, the longest I've had to deal with (without incorporating a bed, at least) is probably *just* over 24 hours door to door [06:21] davecheney, and that was bad enough [06:21] davecheney, if you have flights that long though it may well be worth checking with marianna if you can have an overnight break in an airport hotel [06:22] fwereade: yeah, save my back [06:22] davecheney, I wasn't expecting that, but my very first trip had what would otherwise have been 8 hours on the floor of an airport [06:22] 16 hours LAX -> SYD [06:22] davecheney, swapping that for 5 hours in an actualy bed was very much a good move [06:22] was pretty sore by the end of it [06:22] davecheney, I bet [06:23] oh, and a return trip to POA was > 5,000 AUD, which was the 'piss off, we don't want to do it price' [06:26] davecheney, crikey [06:31] heya TheMue [06:41] fwereade: Morning [07:32] rog, TheMue: I would welcome opinions on https://codereview.appspot.com/6317043 (which, in hindsight, reads somewhat passive-aggressively, but I don't really know what to do about that :/) [07:32] fwereade: Passive-aggressively? [07:33] TheMue, http://en.wikipedia.org/wiki/Passive%E2%80%93aggressive_behavior [07:34] TheMue, the problem is perhaps that I didn't express the issues I had with that approach in those terms during the discussion [07:35] TheMue, in my mind, the assumed context was "it's obvious that this is a lot more work", but that may in fact not have been obvious to all participants [07:36] fwereade: Understand === TheRealMue is now known as TheMue [07:42] fwereade: From a technological perspective LGTM. [07:43] fwereade: But I need more background to understand the problem you want to solve. [07:43] fwereade: Best in some simple words for a "newbie". ;) [07:44] fwereade: i see what you mean :-) [07:45] fwereade, TheMue: mornin' BTW [07:58] rog: Morning [07:58] hmm, my computer just crashed [07:58] if anyone said anything after my "mornin' BTW", i missed it [08:01] rog: Only my greeting after you re-entered the channel [08:01] TheMue: cool [08:05] TheMue, rog: rewritten; is it more helpful now? [08:07] TheMue, btw, wrt what you said earlier, that CL is IMO entirely unnecessary, and that's the reason I was whining so extravagantly in the description [08:08] rog, TheMue: btw, do you have a moment to discuss how I should test charm store access, from outside the charm package, without hitting the real charm store? [08:09] fwereade: sure [08:10] rog, ok... short of screwing up /etc/hosts, what *can* I do? :) [08:11] fwereade: is the charm store address hard-coded into the charm package? [08:11] rog, yeah [08:11] fwereade: well, one possibility would be to make it an exported variable that could be changed by testds [08:12] rog, sure; it just feels last-resorty [08:12] fwereade: of course then you've got to run some kind of your own server [08:12] fwereade: After reading the changed description it's more clear, thx. [08:12] rog, AIUI niemeyer is rather against exposing that at all [08:13] rog, as it is it's a const (because that was my understanding of niemeyer's perspective on the charm store) [08:14] fwereade: If the address is returned by a function we could introduce a package local variable switch by a function SetTestMode(bool). [08:14] fwereade: so what functionality are you needing to test exactly? [08:14] fwereade: When setting it to true the function returns localhost. [08:14] rog, that we can deploy a charm from the charm store [08:15] rog, I think there *may* be a case to be made that InferRepository is properly tested, and both local repos and the charm store are properly tested [08:16] rog, and that therefore hitting just one of the InferRepository code paths is actually adequate [08:16] rog, but my go-testing-fu is not adequate to determine whether this is defensible [08:16] fwereade: that sounds like it may be reasonable. [08:16] fwereade: there's no point in testing the same functionality in two different places [08:17] rog, yeah, that's what my heart says [08:18] rog, but it was hard work forcing myself to test everything a million different times in python when I joined the project [08:18] rog, and I haven't quite figured out how the prevailing rules have changed [08:19] rog, ok, I'll propose it as-is with an explanation [08:19] fwereade: seems reasonable. [08:46] rog, fwereade: Different topic, did you already booked you flights? [08:46] TheMue: yes, i've booked. arriving late sunday evening. [08:47] TheMue, ah yeah, I crash-stopped the booking the other day and haven't redone it yet [08:47] TheMue, ty for reminder [08:47] fwereade: np ;) [08:48] rog: Yes, I'll arrive at 21:45 and depart on Sat at 9:10. [08:50] * TheMue only hopes he's now right with location and date :D [09:21] fwereade: when you say "we discard the actual data and retain only the version." which code are you referring to? [09:21] fwereade: or is this stuff as yet to be written? [09:21] rog, the python, and the proposed code [09:22] fwereade: so, in your view, it would be better to have a ConfigNodeWatcher or something like that? [09:22] fwereade: that passes the settings along as they change [09:22] rog, well, I don't think we need anything other than a map[string]interface{} [09:23] rog, except hmm no [09:23] fwereade: no? [09:23] rog, blast, I haven't fully thought through the cross-relation settings-settings [09:24] fwereade: that, i think, might have been part of gustavo's point [09:24] So, added the flight data to the wiki page. [09:24] fwereade: but explain, please. [09:24] rog, I'm just mainly thinking that there is no reason whatsoever for settings of relations of *other* units to be writable at all [09:24] rog, offering the opportunity to do do so can only lead to bugs and confusion [09:24] fwereade: why does setting *writing* make any difference to what we're talking about, which is *reading* settings, no? [09:25] rog, maybe it's just a slight discomfort with ConfigNodes used in read-only contexts [09:26] rog, (and a ConfigNode can be refreshed, too, which doesn't fit my idea of what we should be doing) [09:26] fwereade: you could return a ConfigNode with a nil zk :-) [09:26] rog, heh, that could work :) [09:27] fwereade: but tbh, why does it matter? we're not going to use it to set values. [09:27] rog: Not nice, better an own type. [09:27] rog, but actually, it's not an issue anyway -- you'll never see changes of your own unit's relation settings [09:27] fwereade: a config node represents a node with settings. we can choose not to write to it. [09:27] rog, so nothing we are ever watching ever has any reason to be anything other than read [09:28] fwereade: i'd be happy if it was <-chan map[string]interface{} too. [09:29] fwereade: is there a problem with that? [09:29] rog, and IMO we shouldn't even offer the opportunity to write it or update it, for similar reasons to those people use to justify public/private distinctions in code [09:29] rog, I'd like that [09:29] rog, ok, people can still write to a map[string]interface{} but at least they have no way of screwing up Zk state by doing so [09:30] fwereade: Otherwise just do a little type struct { data map[string]interface{} } with a Get(string) interface{}. So there's no chance. [09:31] TheMue, indeed, that would work nicely [09:31] TheMue: nah, let them use the map directly. [09:31] TheMue: there's no harm in writing to it. [09:31] TheMue: and then it's easy to range over, etc [09:32] rog, in general my problem is simply with discarding well-sequenced information just so we can approximately reconstruct it later, with additional code to make sure the sequence breaks are less common than they might be [09:32] i'd say either use a map, or a ConfigNode, but not something in between [09:32] rog: No harm to ZK, yes. OK, and the range may be an argument. [09:33] TheMue: an argument? [09:33] rog, I'm not even saying this leads to perfect consistency (config-get is still out of sequence), but it's more consistent with less code and I just don't see the downside [09:33] rog: For using the map directly. [09:33] fwereade: i definitely don't see the point in a version watcher. [09:33] rog, ok, there is a downside: we will store more data locally on the nodes [09:34] fwereade: we've got to get that data anyway, right? [09:34] rog, that doesn't seem to me to be a strong argument for all the extra complexity :) [09:34] rog, indeed [09:35] rog: The ssh.go in state is by you, isn't it? [09:35] fwereade: and the version watcher is fetching all the content anyway. [09:35] rog, yeah [09:35] TheMue: no, that's me [09:35] rog, this is rather my point :) [09:36] rog: You *are* the ssh.go? ;) [09:36] * rog blushes [09:36] TheMue, ssh, we don't want reporters involved [09:36] ;) [09:37] TheMue: i think you meant to say "You are *the* ssh.go?" :-) [09:37] rog: There are several fmt.Printf() in it, are they still needed? [09:37] TheMue: erp [09:37] TheMue: i don't see any fmt.Prints [09:38] TheMue: i see log.Printfs [09:38] rog: Oh, my mistake, just seen log. Sh**! [09:38] rog: So here the prefix "state:" is also still ok. [09:38] TheMue: they're probably a little excessive tbh, but i find them useful for the time being. perhaps they should be log.Debugf's [09:39] TheMue: yeah. [09:40] rog: I'm adding the errorContextf() so I found them and thought it would be debugging code. But in the log it makes sense. [09:40] * rog goes downstairs to get a bowl of cereal [10:02] rog, I was just wondering some more about MachineUnitsWatcher [10:02] fwereade: uh huh? [10:02] rog, as you point out, we can't make a *Unit from a deleted unit [10:03] rog, but how are we keeping track of the things on the other end? might unit names be a better thing to pass around than units? [10:03] fwereade: i suggested that originally, but gustavo didn't like it [10:03] rog, isn't that how the client will be referring to the units in the first place? [10:03] fwereade: and actually, he's right [10:03] rog, bah, ok [10:03] rog, go on [10:04] fwereade: because if you look at the container API, it's phrased in terms of *Units [10:04] fwereade: which seems nice [10:04] rog, ah, ok, that does make sense [10:04] fwereade: although actually it might only use 'em for their names [10:05] rog, I kinda suspect it would ;p [10:05] rog, I have an analogous situation I would welcome input on [10:05] rog, ServiceRelationsWatcher [10:05] fwereade: yup. but... it's entirely possible that it might use more info from the unit for deployment in the future. [10:06] rog, yeah, could be [10:06] fwereade: although then we've got the out-of-date info problem, potentially. [10:07] fwereade: similar thing with ServiceRelationsWatcher, presumably? [10:08] rog, yeah; specifically I suspect we'll have a map[something]*RelatedUnitsWatcher that I'll want to remove watchers from (and stop them) as the service leaves relations [10:09] fwereade: so the ServiceRelationsWatcher is maintaining several watchers? [10:09] rog, I don't *think* it makes sense to use actual *Relations as keys (I should probably reread the spec and find out exactly what it takes to be usable as a map key) [10:10] fwereade: any pointer can be a map key [10:10] fwereade: (anything that defines equality can be a map key) [10:10] rog, no, the unit agent is maintaining several watchers which it starts/stops in response to the ServiceRelationsWatcher's changes [10:10] rog, ok, so actually I should be doing exactly what you're doing [10:11] rog, and define equality on Relations [10:11] fwereade: equality is defined on any pointer [10:11] fwereade: (the pointers are compared) [10:11] fwereade: you can't "define equality" on something [10:11] rog, ok, then that's surely not what I want [10:12] rog, so I had thought, my misinterpretation of your comments gave me hope [10:12] fwereade: what defines a relation in this context? [10:12] rog, the endpoints [10:12] fwereade: i.e. what information would you put in a key? [10:12] rog, hold on a sec [10:13] rog, what do you do in the machine agent when it comes up after an unexpected exit and wants to take down a container for a unit that no longer exists? [10:13] rog, how do you create the *Unit in that case? [10:14] rog, I have to solve the same problem in the unit agent with *Relations, I think [10:14] fwereade: there's no *Unit in that case [10:14] rog, how do you deal with it then? [10:14] fwereade: i have to look at running containers [10:14] fwereade: and see which of them do or don't correspond with current *Units [10:14] rog, and somehow find out what *Units... hmm, ok [10:15] fwereade: when we come up after an unexpected exit, we will never see units deleted. [10:15] rog, and how do you determine correspondence? by name, I presume? [10:15] fwereade: yeah, probably. [10:15] rog, yeah, I'm talking about purely at the agent level, when it has to diff last-known state against what the watcher says is current [10:16] rog, hold on [10:16] fwereade: depends how you store last-known-state [10:16] rog, can you give me an example of when we might want to know anything other than unit name to set up a container? [10:17] fwereade: perhaps the unit's service might have settings that influence how the LXC container is allocated [10:18] rog, isn't it a matter of setting up a named container, and poking in an upstart script to run `jujud unit foobar/17 ...`? [10:18] rog, the unit agent itself should surely be responsible for everything else [10:18] fwereade: i think things are a bit more involved when we're starting stuff within LXC containers [10:18] fwereade: but yeah. [10:19] rog, hmm, I fear I forsee another discussion-heavy afternoon :/ [10:20] fwereade: for your ServiceRelationsWatcher, what would you use that corresponds to the use of unit names in MachineUnitsWatcher? [10:20] rog, that's what I'm asking [10:20] fwereade: for the record, i'm off on holiday at the weekend for two weeks. so good to get the discussions in now... [10:20] rog, I'm inclined to tweak describeEndpoints to sort the endpoints before joining them with " " and using that as a key [10:21] rog, very good to, I'm off thu/fri [10:21] fwereade: ah, so this is last day we're online together before ages away... [10:21] rog, one of those irritating situations where, really, I love to spend time with my family but right now feels rather inconvenient [10:21] fwereade: yeah [10:22] rog, I suspect I'll be sneaking away to work at night occasionally, but I probably won't coincide with you [10:22] fwereade: we'll be in the camper van in cornwall. almost entirely offline. [10:23] rog, cool, have fun :) [10:23] fwereade: you can use a struct as a key BTW [10:23] fwereade: e.g. map[struct{e1, e2 string}] *Relation [10:23] fwereade: so no need to join with " " [10:24] rog, number of endpoints is abritrary [10:24] rog, and I'm pretty sure I can't use a slice as a key, right? [10:24] fwereade: that's right [10:25] fwereade: number of endpoints is arbitrary pending more relation kinds than provides/requires/peer [10:25] ? [10:25] fwereade: or is it not to do with that? [10:25] rog, ATM only possibilities are 1 and 2 [10:25] rog, that's exactly what it is [10:26] fwereade: why can't you use the relation key as a key? [10:27] rog, because I'm pretty certain maintaining the watchers is the unit agent's responsibility, and it doesn't feel like state is the right package [10:28] rog, ahhhh hmmm maybe I could use the relation ident [10:28] fwereade: we could add a Key method to Relation, i suppose. [10:28] rog, we expose that to users, even though it's just a thinly-disguised key [10:28] fwereade: relation ident? [10:28] rog, I'd prefer not to go down that path unless we have to [10:29] rog, for relation-0000000001, it's "relation-1" [10:29] fwereade: that seems like a fine thing to use for a key [10:29] fwereade: especially if it's exposed to users [10:30] rog, we export JUJU_RELATION_IDENT in foo-relation-* hooks so the charm can distinguish between the different runtime relations using the foo charm relation [10:30] fwereade: so maintaining a map of that to *Relation seems ideal to me [10:31] rog, I was thinking more a map of that to RelatedUnitsWatcher [10:31] fwereade: ok, sure. [10:31] rog, which might hold a *Relation, but I'm not even sure that's needed past construction time [10:32] * fwereade slopes off for cig/think time [10:56] hello everyone [11:02] Aram, heyhey [11:10] Aram: hiya [11:40] rog, fwiw, I was wrong: it's JUJU_RELATION_ID, not IDENT, and it's not relation-1: it's relation-name-according-to-service-1 [11:41] fwereade: well, maybe that's a reasonable form for the unit agent to key it on too. because it's not going to hold any relations for any other services, right? [11:42] rog, yeah, agreed, I just wanted to corrcet the misconceptions that might right now be burrowing through your brain :) [11:42] fwereade: rooted out! [12:08] rog, btw, should I do a quick CL for the MustErr watcher stuff we discussed yesterday? [12:08] fwereade: sounds good [12:08] rog, or are you on that? [12:08] rog, cool [12:08] fwereade: nope, i'm on unit agent tests currently [12:09] rog, ah cool, what sort of thing? [12:09] fwereade: oops, i meant machine agent [12:09] doh [12:09] rog, ah rigt :) [12:09] boring :-) [12:13] fwereade: i'm just looking at cmd/juju/deploy.go BTW [12:13] fwereade: i wondered if unpacking the charm in memory is a good idea [12:13] fwereade: perhaps it would be better to store in a temp file instead [12:13] rog, hmm, maybe so [12:14] fwereade: and then for *charm.Bundle you could use the raw file as is [12:14] fwereade: (no need to read twice, even) [12:15] fwereade: 'cos charms could potentially be arbitrarily big [12:15] rog, indeed so [12:18] fwereade: i wonder if the charm.Charm interface should support BundleTo. [12:19] rog, possibly, I'd have to think about it a bit :) [12:20] fwereade: yeah, there may well be a good reason it's not there [12:21] fwereade: at the very least, charm.Bundle could implement BundleTo :-) [12:22] fwereade: although that kinda loses the point [12:29] rog: a new inferno fan: http://debu.gs/entries/inferno-part-2-let-s-make-a-cluster [12:30] Aram: not new - this is the guy that did the post about my shell. [12:30] ah, yes. [12:30] Aram: but it's really nice to see him get excited about it all [12:30] Aram: it still excites me actually, but i've kinda left it behind [12:32] Aram: it's always great to see people play with toys you've made yourself. [12:32] yes, indeed. [12:32] hi niemeyer. [12:33] Hello! [12:33] niemeyer: yo! [12:36] niemeyer, heyhey [12:41] niemeyer, quick check: rick spencer is the head of my business unit, right? [12:41] fwereade: yep [12:42] niemeyer, cool, tyvm [12:45] fwereade: That reminds me of a guy back at Conectiva [12:45] niemeyer, oh yes? [12:45] fwereade: He ranted with someone online on an internal mailing list [12:46] fwereade: A couple of months after joining the company [12:46] fwereade: Then, right after sending his last email to the rant, he asks "Who's that silly guy!?" [12:46] fwereade: "It's your direct manager, dude.." [12:46] niemeyer, haha [12:47] niemeyer, in this case it's just because the travel agent wants to know [12:47] fwereade: Good thing you're not fighting with him yet! ;-D [12:47] niemeyer, but I hope this guy called "sabdfl" I've been insulting isn't anyone in particular ;p [12:47] LOL [12:49] niemeyer, btw, https://codereview.appspot.com/6298097 should be very quite, it's the mustErr stuff we discussed yesterday [12:49] s/quite/quick/ [12:49] fwereade: Looking [12:49] I intend to to a good pass on everything now, btw [12:50] Aram: Specially on yours long standing [12:50] niemeyer, cool, thanks :) [12:51] niemeyer: great, I have charms and units in the queue. === TheRealMue is now known as TheMue [12:59] fwereade: Done [13:00] Grrr, router had a problem. [13:00] niemeyer, cool, thanks [13:11] fwereade: did you run all tests before submitting https://codereview.appspot.com/6298097/ ? [13:12] fwereade: i suspect it may have broken other packages [13:12] rog, oh, crap, I may have just done state/... [13:12] fwereade: yeah, i think it breaks cmd/jujud [13:12] fwereade: though i haven't checked [13:12] rog, I saw a ... in history, and... [13:12] * fwereade hangs head in shame [13:13] rog, you're absolutely right :( [13:15] * rog goes for lunch in the blessed sunshine [13:17] niemeyer, observe screwup above; now I've fixed that and really truly properly verified it's unbroken, what would happen if I were to just lbox propose/submit again in the same branch? [13:18] meh, how can flight search technology be so bad. [13:18] I mean, it's a trivial problem to solve. [13:19] fwereade: Won't work [13:19] fwereade: Just branch it over with "bzr checkout -b -fixup" [13:19] fwereade: and then "lbox propose; lbox submit" [13:19] niemeyer, cheers, will do [13:20] hmm, lbox propose (without -cr) uses the previously created cr on rietveld if it exists? [13:31] rog, it appears to me that there's something up with the container tests as well... [13:31] Aram: Yep [13:31] greta [13:31] great [13:32] Aram: The previous CL/merge proposal/whatever.. it updates whatever was done [13:32] rog, http://paste.ubuntu.com/1050880/ [13:32] Aram: Well, almost.. it won't touch existing bugs [13:33] fwereade: When I now start with ServiceRelation.AddUnit(), would I conflict with you? [13:33] TheMue, yes, please don't touch ServiceRelation, it's gone [13:33] TheMue, what are you planning? [13:34] fwereade: I'm thinking of continuing with the relation methods, but I know you're doing some changes there. [13:34] fwereade: Relation is gone, but ServiceRelation not yet. [13:35] TheMue, I would very much prefer if it we didn't step on each other relation-wise [13:35] fwereade: That's why I asked before. ;) [13:35] TheMue, I have one CL out and a whole *bunch* of stuff waiting in the wings that wants only for agreement and go-ahead on the current bits [13:36] TheMue, there's a missing thing for state.Service though... we don't have any way to set service config [13:36] TheMue, and I think that then implies the whole format 2 business [13:36] fwereade: OK, so I'll concentrate on other parts. [13:36] Aram: Review sent [13:36] thanks [13:36] Aram: Please let me know if you'd like to talk [13:36] fwereade: OK, I'll take a look. [13:37] Aram: Most points should be straightforward, though [13:37] Aram: Glad to see this moving! [13:37] yes! [13:41] fwereade: Todays code only has a get_config. What would you exactly expect from a SetConfig()? Isn't it normally done by retrieving the config, even if it's empty and then do changes and write it again? [13:42] TheMue, huh, you're perfectly right [13:43] TheMue, maybe a look at the format 2 stuff then if you're not too much averse to it? [13:43] TheMue, I had it planned but I seem to have got rather caught up in these bits, and I think it'll take me a few days to burn it down again [13:45] fwereade: No problem, but where do I find infos about the format 2 stuff? [13:46] TheMue, just a mo; I'll collect what I can find for you [13:47] fwereade: Thx. [13:55] niemeyer: right now in ZK we use incrementing integer id's for some thing, this has the property of making nice names (/machine-0, /unit-1-0, etc), but in MongoDB incrementing integers are nasty: http://www.mongodb.org/display/DOCS/How+to+Make+an+Auto+Incrementing+Field [13:55] so so we still want to go with incrementing integers in mongodb, or are random numbers fine? [14:00] Aram: flight search is actually turing complete: http://research.swtch.com/ita [14:00] Aram: A machine id is an integer.. this isn't about MongoDB or ZooKeeper this is the API itself [14:01] niemeyer: I'm not debating whether it should be an integer or not, but whether should be an incrementing integer or a random one :)/ [14:01] Aram: It should remain an incrementing integer [14:01] Aram: 9879872198729831 won't be great :) [14:03] fwereade: ah! i see the problem. i've got jujud in my path, but you haven't. [14:03] fwereade: i think the test should probably create a fake jujud [14:03] fwereade: and set the path to point to it [14:03] rog, sounds sensible [14:04] rog: I know the problem is computationally hard, my issue is that nobody publicly exports the flight data so people could build better 3rd party software than the crap software flight agencies provide. [14:04] Aram: true too [14:04] Aram: Btw, how is it nasty to increment an integer in MongoDB? [14:05] Aram: It's a trivial inc operation [14:06] Aram: I suggest adding a "sequence" collection, where the _id is the collection name [14:06] Aram: and having a sequence(name string) (int, error) helper in State [14:06] niemeyer: so in that link I sent you, you prefer option #1 to option #2? [14:07] that's perfectly fine by me. [14:08] Aram: I prefer to have a scheme as suggested above [14:08] Aram: So we can reuse this next time we need a sequence number [14:09] yes, it's great. [14:09] ok. [14:18] niemeyer: is it possible to create a new bzr branch, but use the same CR as an existing branch? [14:18] Aram: nope [14:18] bummer [14:18] Aram: Well, maybe yes [14:18] Aram: But why? [14:19] niemeyer: I did the mistake of using my trunk for the changes you reviewed, I ported them to a different branch, but that also created a new CR... [14:20] Aram: I think it can be made to work: [14:20] Well, you already created a new CL, right? [14:20] yes [14:20] Aram: Edit the description in the *new* merge proposal, and change the very last link of codereview to point to the proper place [14:21] interesting [14:21] Aram: Then, mark the last branch as Rejected [14:21] Aram: and run "lbox propose" again [14:21] Aram: It's not great to be doing this because the merge proposal will lose part of the history [14:22] ok. [14:30] TheMue: Reviewed https://codereview.appspot.com/6300098/ again [14:30] niemeyer: Just seen, thx [14:30] TheMue: please ping me if you repush soon and I'll have an immediate look so we can integrate [14:31] Aram: Yeah, so we need to do something with this, since it's a copy of the last branch: https://codereview.appspot.com/6295103/ [14:31] niemeyer: Should be only a few moments. [14:31] Aram: Are you doing the trick mentioned? [14:31] niemeyer: yes [14:31] Aram: Super [14:33]