[00:03] fwereade: ping [05:36] davecheney, heyhey [05:36] davecheney, I'm not actually starting work for a little while but I wanted to check in [05:38] davecheney, ISTM that the ultra-short version of what's indicated by the load tests is "we need the internal api" [05:38] davecheney, but we should probably be investigating stuff like the presence pings too :/ [05:49] fwereade: lemmie know when you are free for a chat with our vocal cords [05:49] fwereade: there are some details which aren't captured in your summary, but that is a good first order approximation [05:58] Looking for a review of https://code.launchpad.net/~dave-cheney/juju-core/120-upstart-add-limit-verb/+merge/161275 and https://code.launchpad.net/~dave-cheney/juju-core/119-fix-mongo-ulimits/+merge/161276 [07:06] morning [07:19] * davecheney waves [07:27] fwereade: le ping [07:29] davecheney, la pong [07:29] davecheney, g+? [07:29] TheMue, rogpeppe1, heyhey [07:30] davecheney, fwereade, TheMue: yo! [07:30] fwereade: i'll pop upstairs [07:32] davecheney, fwereade, rogpeppe1: moin [07:56] wallyworld_, ping [09:00] davecheney: just out of interest, do you know how big allmachines.log ended up in your scale tests? [09:00] rogpeppe1: 40-50mb [09:01] uncompressed [09:01] your changes really helped [09:01] but in r 1197 i think some debug logging leaked back in [09:01] davecheney: thanks. and that's after 8 hours or so? [09:01] rogpeppe1: yup [09:01] 1200 machines * 3 hook invocations each == not that much [09:01] davecheney: yeah [09:12] rogpeppe1, davecheney: another thing we could do is to stop logging *all* the hook output and just report what's juju-logged [09:12] fwereade_: actually, i think it's really very useful to see all the hook output [09:12] rogpeppe1, davecheney: possibly store it, and log it if there's an error, but discard on success [09:12] fwereade_: yeah, that could work [09:13] rogpeppe1: i like that [09:13] we don't need to see the hook output in real time [09:13] well, I don't [09:13] maybe the debug-log users do need it [09:13] maybe we need some feedback from the charmers [09:13] davecheney, I can imagine there are some cases peole would expect it, yeah [09:14] davecheney, oh, for real log levels and dynamic switching between them... [09:14] fwereade_: please, don't mention the war [09:16] davecheney, I think it is a reasonably high priority, but yeah, it's not something I really want to think about *today* [09:54] fwereade_, rogpeppe1: https://codereview.appspot.com/8540050 - PTAL [09:56] https://codereview.appspot.com/8797046/ [09:56] https://codereview.appspot.com/8551048/ [09:56] davecheney: looking [09:56] https://codereview.appspot.com/8540050#msg3 << bzzt [09:57] davecheney: what? they changed the not lgtm color to yellow? [09:59] dimitern: the matcher is really stupid [10:00] you can do [10:00] 'there is no way in hell I would consider giving this a LGTM' [10:00] and it will turn green [10:00] :) yeah [10:01] davecheney: 2 LGTM s from me you have [10:01] dimitern: thanks mate [10:02] maybe I should just hard code the values we need [10:02] rather than gold plating it [10:02] davecheney: it's good they're not hard coded I think - less cryptic imo [10:03] dimitern: yeah, that is what I wanted, constant at the top, impl down the bottom [10:06] rogpeppe1: fwereade_ dimitern was any decision made on backporting fixes to 1.10.x ? [10:06] I have been keeping this page https://docs.google.com/a/canonical.com/document/d/1jIxqV-4c06GWIfCpB0pb8nS4frFhKY0k3WwXj5QdytQ/edit [10:06] davecheney: there are a few things that would be worth fixing in 1.10 i think [10:07] davecheney, excellent, I will start using that [10:07] rogpeppe1: would you add them to thise page [10:07] davecheney: will do [10:07] unless there is something that LP will do this for us [10:07] davecheney: what's the significance of 65000 BTW? [10:08] rogpeppe1: i cargo culted that from an issue that I found on the mongo support forum [10:08] probably 40,000 would be enough [10:11] davecheney: you've got two more LGTMs (with minor comments on both) [10:12] rogpeppe1: ta [10:12] davecheney: you might want to include a link to the support issue so at least we know which cargo cult you subscribe to :-) [10:13] ALL PRAISE GOOGLE [10:13] rogpeppe1: it's linked from the LP # [10:13] davecheney: i'd prefer it in the source, 'cos that's where the number has ended up [10:13] rogpeppe1: will do [10:13] can't be bothered doing LP shit tonight [10:13] it's late === rogpeppe1 is now known as rogpeppe [10:45] dimitern, reviewed [10:46] fwereade__: cheers [10:47] fwereade__: well, you're basically rewriting the whole thing with your suggestion [10:48] fwereade__: if you know better, why didn't you do it yourself? [10:49] dimitern, it's not always clear what I know until I have something to contrast it to [10:50] fwereade__: yeah, i understand, but i hope you understand my frustration as well.. [10:50] dimitern, I do :( [10:51] dimitern, I *think* that what I suggested casts the code more neatly in terms of the problem it's solving, but I am actually open to arguments [10:51] dimitern, there may well be a case I'm missing that you handle [10:52] fwereade__: what's not clear with my code, apart from having several flags? i tried to simplify it and comment various parts, so it's easier to follow [10:54] dimitern, it's just that I found it hard to keep track of them all, and there seemed to be more than the problem demanded [10:54] fwereade__: hmm.. ok i'll use your suggested code [10:55] dimitern, it may be that all the complexity is essential, because I've missed at least one case, and I'm undecided whether or nt it's important [10:55] dimitern, can we have a G+ before we decide? [10:55] fwereade__: ok, i'll start one [10:55] dimitern, sorry just started it [10:55] https://plus.google.com/hangouts/_/a8d696030b277037ba7217906ea69be8e9f06a39?authuser=0&hl=en [10:55] dimitern, [11:33] fwereade__: i was at soccer earlier, i can ping you after our standup if you like [11:35] jam: dimitern: standup? [11:51] fwereade__: standup finished if you are around [11:51] wallyworld_, sgtm, would you start one? [11:52] ok [11:54] wallyworld_, I just posted sketchy incomplete comments on https://codereview.appspot.com/8816045/, they will be relevant, but they representa WIP not final thoughts and are inelegant [11:54] ok [11:54] https://plus.google.com/hangouts/_/78899c984df96bf7b6eca6babca07fdad4628c4e [12:06] fwereade__: did the changes and all tests still pass :) - https://codereview.appspot.com/8540050 [12:20] dimitern, sweet [12:21] dimitern, sorry, got to pick up laura now though [12:23] fwereade__: np, when you can [12:23] * dimitern lunch [12:27] Roger Peppe (Juju Core Development, CDO) Roger has been doing great work supporting the Go-Juju port from its inception, and his recent work with the GUI team to implement all of the APIs they needed to port from Python to Go showed diligence, responsiveness, and is a great example of cross-team collaboration. [12:27] ^ good work rogpeppe [12:27] davecheney: thanks. that was a total surprise! [12:27] you deserve it [12:28] davecheney: ta! [12:36] rogpeppe: +1 from me too, have been happy to read it. [12:55] rogpeppe: btw, these thoughts match to yours about logging and error messages: http://joearms.github.io/2013/04/28/Fail-fast-noisely-and-politely.html [13:03] * rogpeppe is back from lunch [13:03] TheMue: thanks [13:05] rogpeppe, also +1 from me, the api is very easy to work with [13:05] mattyw: glad to hear it! [13:55] hey guys, fwereade just texted me his internet connection is down currently [13:56] that sucks [13:56] my internet was down last week [13:56] roger [13:56] has had no internet in forever [13:56] we are having bad internet luck recently [13:56] mramm2: mine is fine, but both my mic and my camera are playing tricks [13:56] mramm2: so i'll just listen and type [13:58] ok [13:58] sounds like it will be a small meeting [13:58] rogpeppe: your internet working yet? [13:58] mramm2: nope [13:59] mramm2: i have a possible fix date though [13:59] mramm2: about 30 hours from now === wedgwood_away is now known as wedgwood [13:59] perhaps we should just do the meeting here on IRC [13:59] or skip it for this morning [14:00] mramm2: +1 for both options [14:01] what are folks working? [14:02] I see frank is working on status output. [14:02] mramm2: i can do G+ through my phone and the expected ghost-like appearance... [14:02] let's do it here [14:02] yea, but dimitern is not able to G+ and fwreede has no internet, so it would be a small contingent [14:02] mramm2: i moved it just back, because i've got only today and tomorrow. i'm working on the blueprints. [14:03] TheMue: thanks [14:03] so that is the other thing, I'll be contacting you individually but I added your names to some blueprints on the eplic backlog [14:04] mramm2: i'm still on upgrade-charm --switch - will appreciate a review from rogpeppe; had a g+ earlier with william and fixed some things, simplified the code [14:04] (true for all of you) and will need your help to fill them in with what we know on the subject already [14:04] dimitern: ah, will review [14:04] dimitern: nice [14:04] rogpeppe: thanks [14:04] (i think that was when g+ broke for me - gtalk plugin crashed and lost sound after restarting) [14:05] mramm2: yes, i've seen mine and i'm pretty fine with them (only right now no clue about the ssh provider) [14:05] i'm about to propose godeps into juju-utils, which should give us the ability to at least do *something* with our dependency management problems [14:05] or actually juju-utils is not the right place [14:05] probably launchpad.net/godeps [14:05] TheMue: that is just a provider that requires that you give ssh keys to an existing machine [14:06] which it will log into and take over [14:06] rogpeppe: if it is multi-purpose for any go-project then lp/godeps [14:06] TheMue: it is [14:06] rogpeppe: TheMue: agreed [14:06] rogpeppe: what's godeps? [14:07] mramm2: aha, ook, thx [14:07] dimitern: here's the usage information for it: http://paste.ubuntu.com/5616028/ [14:08] rogpeppe: so this is basically gofix for imports? [14:08] dimitern: no. it doesn't touch source code. [14:08] dimitern: the idea is that when releasing you'd do (in juju-core) godeps > juju.deps [14:08] rogpeppe: ah, like pip freeze, nice! [14:08] dimitern: then when you want to build the release, you'd do: godeps -u juju.deps [14:09] dimitern: which would update all the dependencies to the expected versions [14:09] dimitern: i think we discussed something similar in atlanta [14:10] rogpeppe: yeah, and i thought hazmat and mgz did some python tool, but never heard what happened next [14:10] dimitern: i don't know either. [14:11] * TheMue is happy about it. so far I helped myself with a simple little script that wonderful fails if new dependencies are added. [14:11] dimitern, rogpeppe its very minimal, basically reads a frozen description and updates the tree to it lp:goreq [14:12] hazmat: how do you get the description? [14:12] hazmat: ah, thanks - will take a look [14:12] rogpeppe, text file, import name space rev per line [14:13] hazmat: so you'd manually do that? [14:13] rogpeppe, at the moment yes, but you could also generate a freeze [14:13] rogpeppe, ideally you could just spec a date, [14:14] and have tree updated to revs from the date [14:14] you really want it manual [14:14] hazmat: i'm imagining that we'll bake the rev file into the tree [14:15] mgz: how so? [14:15] well, some little tool to bump everything and run tests doesn't hurt [14:15] there's a nicer version of the src tree management in the juju-deployer work, that i want to copy over to goreq or setup as a common dep [14:15] but the point is you want specific revs of the deps versioned in the main project [14:16] yea, requirements.txt is the part of pip that is critical, but pip freeze is *very* nice [14:16] mgz: i agree [14:16] mgz: is there a problem with the semantics of the command i outlined above? [14:18] I don't completely understand it from that --help, but in short update is hard to do correctly (that shouldn't stop us making a start on this) [14:19] mgz: why is it hard? [14:19] mgz: i haven't done it yet, but i'm assuming it's as simple as "check it's clean; bzr update -r revno (or similar for other vcs's)" [14:20] what does the tool do when I have a different branch checked out in bzr, or a different head in git, or am on a different branch in hg [14:20] you need a vcs specific bits of sanity code [14:21] mgz: presumably the vcs will error that the particular revision id is not available [14:21] this is mostly a problem where it's trying to do all the deps in one go, you'll generally expect someone to be able to resolve an issue in the branch that's cwd [14:22] mgz: i was not planning on using revision numbers BTW (except as extra info in the file for user consumption only) [14:22] mgz: i still don't quite see the issue, i'm afraid [14:24] just knowing the working tree is clean isn't enough [14:25] mgz: i was planning on doing a cleanliness check in all the deps too [14:25] mgz: and making sure that they're all updated to the versions as specified in the deps file [14:26] it's possible to say, update my feature branch of goose to a new trunk rev, but it's impoilite as it changes the meaning of the branch, and makes it annoying to get back my work [14:26] the point is "cleanliness check" is hard, and hard in different ways for the different vcses [14:27] mgz: ah. i thought there was an equivalence of "bzr status" for all of them [14:27] mgz: git certainly has one. and hg too. [14:28] s/equivalence/equivalent/ [14:28] there is, but that only tells you about the working tree state, not about the branch [14:28] mgz: i take your point about changing the feature branch to something else [14:28] mgz: i think that's unavoidable unless we want to make a new copy of everything [14:29] mgz: which is one possible approach [14:29] mgz: another is: godeps > /tmp/old; godeps -u something.deps; go build; godeps -u /tmp/old [14:30] mgz: i.e. it makes it easy to save your current state and revert to it [14:32] so, a script runnable by devs is reasonable I think, but we also want the export thing (it's basically what my tarball construction did) [14:33] mgz: yes, the export thing is orthogonal [14:33] mgz: and useful in any case [14:34] mgz: i don't think it has to be part of the same command [14:34] there's nothing wrong with starting out dumb and improving it, there are just going to be some gotchas until it grows some vcs smarts [14:34] it should consume the same file [14:34] mgz: possibly. although it could just consume go source. it doesn't really need to know anything about vcs [14:35] it wants to know what revs of the deps need to go in the tar [14:35] the deps file has that information [14:36] mgz: wouldn't this work ok? go deps -u v1.10.0.deps; goexport mypkg [14:36] mgz: i.e. it would just work with the go source as it finds it === andreas__ is now known as ahasenack [14:37] sure, so goexport is a thing? [14:37] mgz: it would still need to know about the dependency graph, but that's trivial with the go build package [14:37] the point is that's hard to implement robustly [14:37] mgz: that's my provisional name for a non-hacky version of your script [14:38] whereas it's easier to just export rather than update, then copy that [14:38] because update is not a clean operation [14:40] mgz: hmm, possibly. [14:41] mgz: i'd kinda prefer to isolate the vcs smarts to one place though [14:53] hi guys, is there an ETA for having this bug handled? https://bugs.launchpad.net/juju-core/+bug/1121907 [14:53] <_mup_> Bug #1121907: deploy --config

[14:53] the option exists, but does nothing [14:58] ahasenack, funnily enough that one just reached the top of my list [14:58] :) [15:02] hm, in pyjuju, relation-list has the -r option: -r RELATION ID [15:02] does relation-list in juju-core has something similar? I'm looking through the code and docs [15:02] or is it without the -r? [15:12] ahasenack, it seems as though it accepts it as an (optional) arg, not a flag -- I have no recollection of how this decision came about [15:12] fwereade: you mean just foo.yaml, not --config foo.yaml? [15:13] ahasenack, ah sorry I'm talking about relation-list [15:13] ah [15:13] fwereade: yeah, I just hacked the charm I was testing to omit -r and it installed now [15:13] fwereade: but you will need to put -r back if you want to remain compatible with pyjuju [15:13] fwereade: https://bugs.launchpad.net/juju-core/+bug/1172895 [15:13] <_mup_> Bug #1172895: relation-list incompatibility with pyjuju: -r [15:14] ahasenack, quite so [15:14] initially I thought it was something like a short-name and long-name option thing [15:14] like -r vs --relation-id, and only the long one was supported [15:14] ahasenack, consider that higher-priority than --config, because at least I can do that quickly and the code won't make me want to set fire to things ;p [15:15] :) [15:17] do you guys have a go syntax highlighting file for vim by any chance? Raring doesn't come with one it seems [15:20] ahasenack: it should be in the misc folder [15:21] I'm searching the packages I have installed, no luck so far [15:21] will grab it from the code repo then [15:22] ahasenack: i'm just looking [15:22] ahasenack: but i have to admit i've installed go directly ;) [15:24] ahasenack: did you also install vim-syntax-go? [15:24] TheMue: oh, no, there you go [15:25] TheMue: apt-cache search "go" doesn't help much, that package should be called vim-syntax-golang [15:25] uh, it wants to install ruby [15:25] * ahasenack --no-install-recommends [15:26] ahasenack: yes, would be better. the emacs file is named golang-mode, the kate file kate-syntax-go *hmpf* [15:28] that package doesn't seem to work... [15:28] the vim one [15:29] *sigh* [15:29] going back to the one from the source, that worked [15:29] http://go-lang.cat-v.org/text-editors/vim/ with these instructions === hatch is now known as eric_f === eric_f is now known as hatch [15:40] https://codereview.appspot.com/9015043 if anyone's interested [15:40] * dimitern nags: https://codereview.appspot.com/8540050/ [15:45] * fwereade apologises to dimitern, just a couple of last points, just sent [15:48] dimitern, fwereade: i'm having difficulty persuading myself that this line is correct: if *newURL == *oldURL && !explicitRevision { [15:49] rogpeppe, it's not [15:49] fwereade: good, it's not just me then [15:49] rogpeppe, explicitRevision shouldn't come in at that point [15:49] fwereade: oh, interesting, i thought the other way round [15:50] fwereade: that the urls shouldn't come in at that point [15:50] rogpeppe, I don't think explicitRevision matter except when choosing whether to bump -- because bumping when a specific rev is already specified is clearly insane [15:50] fwereade: because i think i've persuaded myself that it may be useful to bump the revision even when the new url is different [15:50] rogpeppe, whereas that whole block is all about what happens if it seems there's actually nothing to upgrade to [15:51] fwereade: "bumping when a specific rev is already specified is clearly insane" - isn't that what the explicitRevision check is checking for? [15:51] rogpeppe, yes, it's meant to stop that happening, in my mind [15:52] fwereade: yeah. so we need explicitRevision in that test, no? [15:52] rogpeppe, definitely not [15:52] rogpeppe, what about a service running the latest charm from the charm store? *oldURL == *newURL [15:52] rogpeppe, so we want to get in there and hit "already running latest charm" [15:53] fwereade: hmm, yes, good point [15:53] fwereade: but the case i'm thinking of is something like this: [15:54] fwereade: we have a local copy of a charm, deploy it, push it to the charm store, switch to that, then make some changes to the local copy and switch back to that [15:54] fwereade: in that case, we want the version to be bumped, but the urls are different [15:55] fwereade: i'm wondering if the local charm test should be at the outer level [15:55] rogpeppe, hmm [15:56] fwereade: so we always bump version if the charm is local [15:57] rogpeppe: we bump when the target url will be the same as the source one, the repo is local and the charm is a dir [15:57] rogpeppe, I'm pretty sure that causes unwanted behaviour when upgrading to s epcific version [15:57] rogpeppe, hey, you have v33 and v34 in your repo [15:57] rogpeppe, you asked for 33 so I changed it to 34 [15:57] rogpeppe, no need to thank me [15:57] fwereade: ah yes, we should bump version if the version isn't explicitly specified *and* it's local [15:58] rogpeppe, I *think* so yes [15:58] fwereade: that's exactly what this !explicitRevision case is there for [15:58] dimitern, but it breaks the no-newer-version-in-charm-store case, doesn't it? [15:58] dimitern: see my thought experiment above: [15:58] rogpeppe, dimitern: bumpVersion is crazy broken anyway though [15:59] fwereade: local charms are crazy broken :-) [15:59] rogpeppe, dimitern: true [15:59] fwereade, rogpeppe: i lean more and more towards having --bump-revision as explicit argument [15:59] dimitern: as it was originally [15:59] dimitern: yeah [15:59] and leave all the trickery to user's consent [15:59] dimitern: i think i agree [15:59] dimitern, rogpeppe: hmm [16:00] dimitern: don't be tricksy unless i specifically say so [16:00] then at least the user is aware that there's subtle magic going on [16:00] rogpeppe: exactly, even "dump" - if --bump-revision is specified, we *always* do it, if possible (local charm + dir) [16:00] s/dump/dumb/ [16:00] rogpeppe, dimitern, if I had to I think I'd come down on the side of --no-bump-revision [16:01] fwereade: that doesn't really help [16:01] fwereade: we'd need all the same heuristics we have now [16:01] fwereade: yeah, don't see how this helps [16:01] fwereade: the nice thing about --bump-revision is that we can ditch all of 'em [16:01] rogpeppe, dimitern: it solves the use case, which --bump-revision doesn't really [16:02] fwereade: depends if you think that the magic is really worth it [16:02] fwereade: --bump-revision doesn't claim to solve anything - it's just an explicit request from the user [16:02] dimitern, then it's a regression [16:02] fwereade: with --bump-revision, the model is very clear [16:03] fwereade: so less surprises to the user, i think [16:03] yeah, my point exactly [16:03] fwereade: i agree that the user will have to type a bit more though [16:03] fwereade: but if they don't, they'll get an error message [16:04] rogpeppe, dimitern: and it breaks compatibility, doesn't it? [16:04] fwereade: really? did py juju do auto bump? [16:04] rogpeppe, yes [16:04] rogpeppe, it's hugely popular [16:04] aw shucks [16:04] fwereade: in a good way - compatibility shouldn't be absolute if it forces us to twist things like that [16:04] ok then, we have to do it. but let's get it right at least. (whatever that means :-]) [16:05] fwereade: how can you tell that? [16:05] dimitern, in a "we no longer solve a big and expensive problem for users" way, really [16:05] dimitern, because they asked for it, and we gave it to them, and there was great rejoicing [16:05] fwereade: the users are not as dumb as we think they are perhaps [16:05] dimitern, because nobody spent 20 mins with N machines on the clock trying to figure out why their fixes didn't work any more [16:06] fwereade: getting a meaningful error when you go wrong is helpful, not getting an error and subtly screwing up in hard to determine ways is, imho [16:07] fwereade: so i'm asking again - do you want to take that one over and do it how you think it will be ok? [16:08] dimitern, I'm not regressing this unless we can determine a better story for charmers than the one we have [16:09] fwereade: i feel more and more out of my league here - doing things I'm not getting completely all the repercussions [16:09] dimitern, the user expectation is that, when upgrading from a local repo, a new charm will be bundled with a new revision [16:10] dimitern, I *think* that an explicit request for some other rev should probably override this though [16:10] fwereade: how about --revision # or --switch=blah-# ? [16:10] fwereade: s/a new charm/the charm/ ? [16:10] * fwereade knows the feeling [16:10] fwereade: ok, so I think I covered that, didn't i? [16:10] dimitern, those are I think explicit revisions, but you do the test in the wrong place [16:11] dimitern: i don't think your code covers this scenario: [16:11] [16:54:14] fwereade: we have a local copy of a charm, deploy it, push it to the charm store, switch to that, then make some changes to the local copy and switch back to that [16:11] fwereade: where should the test be then? [16:11] dimitern, the whole `if *newURL != *oldURL` block is about eliminating situations that imply we can't bump [16:12] fwereade: or bump it if needed [16:12] dimitern, I'm just suggesting another check in that bails out with "already running that charm" if the rev is specified explicitly [16:12] fwereade: actually it's exactly when to bump, by default we never bump [16:13] fwereade: when? as a last check or first? [16:13] * fwereade shrugs -- first maybe? [16:13] fwereade: so basically would "bumpRevision = !explicitRevision" do that in the last block? [16:14] dimitern, doing it first of all seems neater -- we can have an message tailored to its explicitness [16:14] fwereade: ah, you want an error as well, ok so it looks to me it's likely to be the last check before setting bumpRevision to true [16:14] dimitern: bump-revision = charm is local and revision is not explicit [16:15] dimitern: ? [16:15] dimitern, if we don't hit that, the existing "already running latest" bit makes more sense [16:15] fwereade: if it's first, we won't handle the case when we cannot bump anyway - be it cs: url or a bundle [16:15] dimitern, if it's first we give the best error message for the situation, I think [16:16] fwereade: so "already running latest charm cs:blah-12" is a better error? [16:16] dimitern, well "latest" is a problem if it's an explicit revision [16:16] dimitern, it only becomes appropriate once we've eliminated the explicit case, at which point we can be sure the new url is the latest one [16:17] fwereade: then (and i though that before as well) these 3 error cases should be different [16:17] fwereade: having the same msg 3 times seems confusing [16:17] dimitern, could very well be, it's always a good thing to improve the error reporting [16:18] fwereade: how about "already running latest charm X: - explanation" and the explanation will be different in each cas [16:18] case [16:18] dimitern, "latest" doesn't always apply [16:19] dimitern, "already running specified charm" and "already running latest charm" seem to cover reasonably well, but a 3rd "cannot bump revision of local charm bundle" might be reasonable [16:20] fwereade: ok then "cannot upgrade to charm X: - [explicit revision matches latest|not a local repository|not a directory]" > [16:20] ? [16:20] dimitern, the "latest" and "explicit" cases are different [16:20] dimitern, we never even check latest when there's an explicit revision [16:22] fwereade: ok, agreed - but i still think the 2 cases for latest could be reported differently [16:22] dimitern, "already running latest charm" is way more important then "not local" or "not dir" -- the local bumping is a special case that we only get out when we;ve eliminated reasons not to even try [16:22] dimitern, I would be fine differentiating them [16:22] fwereade: those error messages sound good to me [16:22] fwereade: ok, so with these changes it should be good to land then? [16:23] rogpeppe, dimitern: the "charm X" is particularly a problem in a wanted-to-bump-revision context [16:23] rogpeppe, dimitern: that's kinda a side effect of PutCharm's revision-changing [16:24] fwereade: i'm not following you there i'm afraid [16:24] dimitern: +1 [16:24] fwereade: you mean the wording or the logic? [16:24] rogpeppe, dimitern: "cannot upgrade to charm X" when we wouldn't actually be upgrading to that revision [16:24] rogpeppe, dimitern: I'm fine changing them but I would like them to be more accurate not less [16:25] fwereade: totally agree on that [16:26] dimitern, I think we're reasonably clear on the logic regardless [16:26] mgz: stupid question: what's the accepted way of creating the initial branch for a project? [16:27] mgz: i've created lp:godeps, but i've tried bzr push lp:godeps/trunk; bzr push lp:~rogpeppe/godeps/trunk; bzr branch lp:~rogpeppe/godeps/trunk and others [16:27] dimitern, so with that fixed I'd gladly LGTM with maybe a suggestion for different messages [16:27] niemeyer: ^ [16:28] you push it to a n normal location, then set that as the trunk in launchpad [16:29] so, eg, lp:~juju/godeps/trunk or lp:~gophers/godeps/trunk or something [16:29] rogpeppe: ^ [16:29]