[00:41] wallyworld_, thumper: should have you a working maas in about an hour, need to download 300MB of updates and re-commission nodes [00:42] rightio [01:39] * thumper noticed that the ubuntu edge igg has stalled just under 7m [01:40] bigjools: if you could fling wallyworld_ and me the details for the environments.yaml file, that'd be swell (when it's ready) [01:40] I will [01:46] what is a MIR ? https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-mongodb [01:48] * thumper looks [01:49] davecheney: where is MIR mentioned? [01:50] ah [01:50] Main Inclusion Request [01:50] AFAIK [01:50] at least that is what I think it is [01:51] I only know MRE [01:51] which is? [01:52] Meals Ready to Eat [01:54] haha [01:56] wallyworld_: I noticed today that when I started up a second machine on ec2, and it had two ccontainers on it [01:56] wallyworld_: when the lxc provisioner task started, it didn't get told about the new containers [01:57] so they never started [01:57] the two containers on machine 0 started [01:57] but their machine agent would have been running first [01:57] thumper: which ssh key of yours should I put on here? [01:57] whereas the machine 1 would have been booted after the two containers in state [01:57] * thumper looks [01:57] it should have queried state [01:58] wallyworld_: I agree, it should have [01:58] wallyworld_: but it does that by starting the watcher [01:58] you think this is a new bug? [01:58] wallyworld_: what I'm saying is that something is screwy there [01:58] probably [01:58] may need some more poking [01:59] afaik the watcher returns the inital state of play [01:59] yes it should [01:59] but it seems in this case, it didn't [01:59] I probably need some extra tracing... [01:59] so i wonder what has changed. i can't recall any of us touching this stuff [01:59] no [01:59] but the machine agent has had some messing around with the state -> api stuff recently [02:00] hmmmm [02:00] also, general watchers have seen change since this worked before [02:00] thumper: ? [02:00] bigjools: I dm'ed you the key [02:00] ah nm got it [02:00] was looking on LP and you have loads [02:00] yeah [02:00] jake is the current machine [02:00] elwood was the last one [02:01] jake is my eldest twin's name [02:01] :) [02:01] what did you call the other? [02:01] he's getting better, thank goodness [02:02] Harley [02:02] you missed an opportunity there [02:02] s/missed/avoided/ [02:02] there was a funny facebook message the other day about nature names [02:02] Dragonhunter FTW [02:02] /o\ [02:03] luckily for the children, i can't have any more [02:03] unless advances in stem cell research changes things [02:43] thumper: any chance you could review this branch for me: https://codereview.appspot.com/11923043/ ? [02:43] jtv: there is always a chance [02:43] * jtv rolls dice [02:44] davecheney: my information is that MRE stands not for Meal Ready to Eat, but Meal Rejected by Ethiopians. [02:55] * thumper starts reviewing [03:01] done, school pickup, back shortly [03:26] * thumper considers a branch that allows setting log levels remotely [03:45] *sigh* gotta go see the neighbour, fence fell over [03:45] bbs [03:54] :( === thumper is now known as thumper--afk === tasdomas_afk is now known as tasdomas [07:38] Morning guys… I've got a tiny branch up for review… in case someone is free to review it: https://codereview.appspot.com/11913043/ [07:58] morning [07:59] morning [08:00] rvba: reviewed [08:00] axw, TheMue: mornin' [08:01] Thanks a lot rogpeppe. [08:01] hey rog === TheRealMue is now known as TheMue [09:07] dimitern, fwereade: thanks for the reviews; responded. https://codereview.appspot.com/11932043/ [09:12] rogpeppe: me too :) (replied to one of your comments) [09:13] dimitern: i like the idea of reusable constructs for writing tests, but not when using them is more work than doing the basic version. [09:14] dimitern: i don't think statetesting.AssertStop gains us anything at all [09:14] rogpeppe: how can it possibly be more work? [09:15] rogpeppe: don't you use code completion? :) [09:15] dimitern: is that why it's less work? [09:15] dimitern: it's also less obvious than the basic version [09:15] dimitern: and i like to keep test code as simple as possible [09:16] dimitern: it should really be called AssertThatStopSucceeds [09:16] rogpeppe: ohh.. [09:17] rogpeppe: :) well, ignore me then, but my point was to enforce consistency when possible [09:17] rogpeppe: otherwise each module can be its own world because it makes sense there and then, rather than having a codebase-wide uniformity [09:18] Hi folks — how's tarmac doing today? [09:18] jtv: still dead i think [09:18] * jtv wipes away tear [09:19] Did I hear mention of a workaround? [09:19] dimitern: Assert(x.Stop(), IsNil) seems about evenly balanced with AssertStop in the code base [09:19] jtv: manual landing [09:19] I don't think I have privileges for landing. :( [09:19] mgz: can you explain jtv about how can he land his code manually? [09:20] * rvba listens [09:20] * jtv turns on the water heater in anticipation [09:20] rogpeppe: and if it was s.AssertStop(c, w) would it be better? [09:20] dimitern: not really. [09:21] dimitern: i like to see the Stop call directly in the code. [09:21] rogpeppe: so you're not complaining about the length of the idents [09:21] FWIW for me as an outsider, Assert(x.Stop(), IsNil) is a lot easier to understand. Might I suggest a compromise of "AssertStopSucceeds"? [09:22] dimitern: not really. just the fact that it's a single line of code which i think is clearer written out each time than calling a function to do it [09:22] rogpeppe: how about statetesting.AssertCanStopWhenSending then? [09:22] jtv: exactly. [09:22] jtv: thanks [09:22] rogpeppe, dimitern: fwiw you can also defer AssertStop without dropping errors on the floor [09:22] fwereade: ah! very good point [09:22] fwereade: now *that* is a good reason for using it [09:22] rogpeppe, dimitern: and once you're using it in one place you may as well keep doing so IMO [09:23] exactly [09:23] jtv, rvba: well don't know if mgz is around, but basically the process goes as follows [09:24] rogpeppe, dimitern, jtv: and while we're bikeshedding -- AssertCleanStop? [09:24] The hard part is expressing both the side effect and the assertion. [09:25] jtv: yeah [09:25] 1) switch to trunk, 2) pull, 3) bzr merge lp:~user/juju-core/yourbranch, 4) go build ./... && go test ./... (in juju-core/), 5) if all pass (and assuming no live testing is needed), 6) commit locally, setting the commit message as in LP, 7)bzr push bzr+ssh://go-bot@bazaar.launchpad.net/~go-bot/juju-core/trunk [09:25] jtv: rvba ^^ [09:26] 8) set MP to Merged + set revision in LP [09:26] dimitern: I odn;t think red squad have hte bot creds [09:26] step 7) requires you to have access to go-bot's branch [09:27] or rather, red squad's ssh keys aren't on the launchpad bot accout [09:27] mgz: ah, right, but did i summarize it well? [09:27] ypu [09:27] dimitern: thanks, that push URL was the part I was missing of course. [09:27] Should I give it a try anyway? [09:28] you can bzr info i [09:28] *it [09:28] jtv: perhaps after all is done, you could push it to lp:~user/juju-core/trunk and let me or mgz push it to trunk for you until the ssh keys are sorted [09:29] running the test suite after merge and setting commit message in the mp will do [09:29] I can land pretty easily after that [09:30] mgz: "bzr info" says permission denied. :( [09:30] right. [09:30] But yes, I guess I could just merge all my approved branches into a personal trunk for the time being. [09:30] I think bzr has just implemented netsplits. [09:30] oh, that would work too [09:31] I thought that was what you meant when you said "push it to lp:~user/juju-core/trunk".. ? [09:31] Sorry, what Dimiter meant. [09:32] well bundling lots of changes up there saves some time [09:33] * fwereade_ is going to try to find somewhere with coffee, bbiab [09:34] jtv: but please, get in line so we won't introduce conflicts/breakages [09:34] ideally, after bzr pull on trunk, run go build ./... && go test ./... before starting to merge to make sure trunk is sane [09:34] perhaps we could make lbox submit work again for the time being [09:35] rogpeppe: I don't think this is a good idea [09:35] dimitern: ok [09:36] rogpeppe: doing it manually will enforce some discipline and when the bot comes it'll be easier to switch [09:36] dimitern: at least lbox submit checks that the code builds and is gofmt'd [09:36] dimitern: no need for that command line when just the age-old conventional "make check" will do. :-) [09:36] It has the added advantage of giving clear failure output at the end if the tests failed. [09:37] With the manual command, any test failures may have scrolled out of view. [09:38] Or "make build check format" to combine building, testing, and formatting. [09:43] Anybody willing to review https://codereview.appspot.com/12018043 ? [09:43] jtv: i'll take a look [09:44] Thanks [09:45] And another review from my side: https://codereview.appspot.com/11910043/ ? [09:45] Looking [09:46] Oh, I already approved that one so I don't qualify. :) [09:47] TheMue: will take a look after jtv's review [09:48] dimitern: great, cheers [10:01] fwereade_: making a juju validate super command didn't work out very well. there were a number of dead ends, especially wrt flag processing for sub commands. the juju cmd infrastructure is really only designed for only one level of sub command off juju. so it will be easier just to land as is for now [10:02] dimitern: i got this error trying to push to trunk as suggested: [10:02] bzr: ERROR: Server sent an unexpected error: ('error', 'AppendRevisionsOnlyViolation', 'Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "chroot-74851280:///~go-bot/juju-core/trunk/".') [10:02] jtv: reviewed [10:03] anyone got any idea what that error means? [10:03] Thanks dimitern [10:03] rogpeppe: you messed up the merge :) [10:03] rogpeppe: hmm, not really - perhaps mgz or some lp/bzr guys? [10:04] mgz: ok, so *how* did i mess up the merge? [10:04] Might it mean that somebody pushed something during your pull/merge/commit/push? [10:04] if for instance you merge trunk into your branch, then try pushing your branch over trunk, you get [10:04] Which then wouldn't be in the revisions you were trying to push? [10:04] jtv: i'd have expected a "branch has diverged" error in that case [10:04] you have all the revs, history hasn't diverged, but you rearranged it's order [10:04] ah, i know what i did wrong! [10:05] if anyone cares about debug-hooks, I've got it working now: https://code.launchpad.net/~axwalk/juju-core/lp1027876-implement-debug-hooks/+merge/177353 [10:05] I'll add more tests tomorrow, and hopefully propose it [10:05] Thanks for the review dimitern [10:05] i forgot to pull from trunk before merging [10:06] jtv: yw, tried to adhere to the way you prefer reading them :) [10:06] axw: nice one! [10:07] dimitern: I noticed. Thoughtful of you — it really helps. [10:07] gtg, night folks [10:08] nn axw [10:08] jtv: it's strange that even though I put a blank line before every comment, not all of them appear like that in the mail [10:08] No, Rietveld is sneaky and likes to remove them when you edit them. [10:08] jtv: aahh! good to know [10:11] dimitern: seen your s/. Foo /. Foo/ statements in a review. it seems to be a convention for some of us to use two spaces after a point. i already wondered too. [10:12] TheMue: That's madness :) [10:12] TheMue: the only way I've seen this happen is when I use M-q in emacs to auto-format and align a comment block [10:12] dimitern: dunno, maybe it's normal in some countries. but not in Germany. [10:13] dimitern: ah, emacs, may be a reason. [10:13] TheMue: when you have // ...something.\n// something else. M-q will make it // ...something. something else. [10:13] (2 spaces after the .) [10:14] dimitern: strange behavior, would like to know the reason [10:18] TheMue: perhaps, as with everything in emacs, it's configurable, but I don't know [10:19] It's something I learned in my typing course. I find it greatly helps legibility, especially with the weird stuff we type with lots of dots that aren't full stops. [10:19] ha! I found it [10:20] it's called "sentence-end-double-space", and if set to nil won't do it [10:20] There is a rant on the internet that says it's nonsense, and people who oppose double-spacing invariable point to it with no more than the implication that since it's on the internet, it's the unassailable truth. [10:20] The rant starts out with a few inobtrusive assumptions: [10:21] (1) There is no such thing as monospace fonts, anywhere in the world, ever. [10:21] LOL [10:21] hehe [10:21] i'd stop reading after (1) :) [10:21] i know possibly only one person ever who used proportional fonts while editing code [10:22] (2) Software such as LaTeX can reliably tell the difference between a dot and a full stop, despite the fact that it regularly needs help telling them apart. [10:22] dimitern: :-) [10:22] dimitern: i know quite a few :) [10:22] So do I... Never could quite bring myself to try it. [10:22] Should I proceed with assumption (3)? [10:22] why try it - it's *evil* [10:23] dimitern: ha ha [10:23] dimitern: you get more legible text in less space. what's not to like? [10:23] Sometimes I think I'd like an IDE to render unformatted block comments as flowing, proportionally-kerned text. [10:23] Funnily Smalltalk environments often use non-monospace fonts and still format their methods (because that's what you see in the code browser) in a very aesthetic way. [10:23] SmallTalk. So far ahead the rest of the world will never catch up. :) [10:24] jtv: Smalltalk, not SmallTalk :P [10:24] reading fiction and reading code is quite a different thing and requires different focus [10:24] I believe it. [10:24] jtv: A wonderful language for some domains, sadly very bad regarding concurrency and distribution. *sigh* [10:25] when i'm reading code I notice characters, then words, in fiction, I rarely notice such things, because they won't induce a compile error :) [10:25] dimitern: NOT? *rofl* [10:25] Maybe "fiction" is not quite the right word. [10:25] Because some code is fictional, and much non-code writing is nonfiction. [10:25] ok then, natural text? [10:25] Sure. [10:25] Running text. Human-readable text. Prose. [10:26] (Prose isn't so good because it raises the question: what about poetry?) [10:26] Isn't code pure ficction? The idea of something that happens? :D [10:26] No, in code we oppose a sea of troubles and by opposing end them. [10:27] Which I feel is nobler in the mind than suffering the guns and roses of outrageous fortune. [10:27] And introduce new troubles. [10:27] I don't think the Bard mentioned secondary bugs. [10:27] reminds me of wordpress' moto "code is poetry" :) [10:28] Then again, he didn't actually say "guns 'n' roses" either. [10:28] All code should be in dactylic hexameter. That'll stop idiots from knocking out crud without thinking. [10:28] Quidquid id est timeo danaos et dona ferentes. [10:28] Ouch [10:29] :D [10:29] Next round: Isn't LISP the pure incarnation of poetry? [10:29] *duck* [10:29] I prefer Scheme [10:30] dimitern: me too [10:30] Common Lisp! Variables! [10:30] why do you need variables when you have lambdas? :) [10:30] Ich weiß nicht was soll es bedeuten / das ich so traurig bin / eine Routine aus ur-alten Zeiten... [10:31] even I got most of this [10:31] jtv: Hey, wow [10:31] it my poor german [10:31] TheMue: sorry, didn't mean to insult your cultural heritage. :-) [10:31] *with [10:32] But I do feel like that sometimes when I read ancient functions. [10:35] jtv: no problem, only have been surprised [10:35] trivial CL (func rename and arg reorder) https://codereview.appspot.com/12021043/ [10:35] TheMue: reviewed [10:36] TheMue: what surprised me is that quite possibly the most beautiful German I've ever heard was an American reciting that poem off the cuff... [10:36] dimitern: cheers [10:36] rogpeppe: question about godoc [10:36] TheMue: go on [10:37] rogpeppe: the line break after // ...directory. (line 54 in upgrader.go). [10:37] rogpeppe: will it be visible in the godocs too? your intention seems to be a paragraph, isn't it? [10:37] TheMue: godoc will reformat the whole thing into one paragraph [10:38] TheMue: i should probably cfmt the comment [10:38] rogpeppe: you have my vote. [10:38] jtv: thanks [10:38] rogpeppe: that's what I expected. [10:38] rogpeppe: won't an empty line render as a new paragraph? [10:38] TheMue: yes [10:39] TheMue: i didn't really intend them to be different paras [10:39] rogpeppe: ah, ok [10:39] rogpeppe: reviewd [10:39] TheMue: thanks [11:03] * TheMue => lunch [11:03] hm, no mail since friday, must be imapclean day [11:05] another pretty trivial CL: https://codereview.appspot.com/12025043 [11:09] rogpeppe: does the upgrader now use the API? [11:10] dimitern: yes [11:10] dimitern: although cmd/jujud doesn't yet use worker/upgrader [11:10] rogpeppe: ok (updating the blueprint) [11:10] rogpeppe: also, you've got a review [11:10] dimitern: thanks [11:22] Hi all. In theory I am joining the juju dev team today, though HR/IT/whoever has not actually given me any login information. So I figured I'd just come here and say hi. [11:24] natefinch: hey! welcome aboard! [11:25] natefinch: so you'll be working on juju-core or on some related project, like the gui, etc. ? [11:26] natefinch, welcome! [11:26] Hi, thanks. You'll have to forgive me if I am not up on my IRC skills... it's been... oh god, like 15 years since I was last on irc, in college. [11:27] I'll be on juju-core, from what Mark Ramm said [11:27] natefinch, not to worry :) [11:28] dimitern, hey, did the last one we released actually use the api for the machiner? or did that not get in in time? [11:28] fwereade_: I think it did [11:29] dimitern, oh bugger [11:29] dimitern, ah well, not to worry [11:31] mramm: Morning, Mark. This appears to be the only place I can access currently, FYI. [11:31] ok [11:32] fwereade_, rogpeppe, wallyworld_: standup [11:33] i would if the stupid google plugin would upgrade [11:33] natefinch: heya, welcome here in the channel too [11:33] natefinch: if you want to join the daily standup: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471 [11:33] awesome, thanks [11:34] TheMue: plugin installing... forgot I hadn't done that yet [11:43] hope i'm not intruding, but is there anyway to do https://bugs.launchpad.net/juju-core/+bug/1089291 manually atm? like modifying the mongo db? [11:43] <_mup_> Bug #1089291: terminate-machine --force [11:54] mramm, natefinch: IS has the ticket for nate's new staff task, but it seems no one is on to get started with it yet. [11:55] alexlist is giving me a hand [11:55] mgz: yea I see nobody is on vanguard yet [11:55] ace, if alex is handling it that's fine. [11:56] Nobody around until deej starts working today ... looks very holiday-ish today ... [12:09] * dimitern lunch [12:37] dear go, have working juju on lcy02 finally [12:37] that was painful [13:16] lunch [13:27] warning all, the bot is up but not yet tweaked into happiness [13:27] I'll mail the list when I get it rolling properly again [13:43] mgz: thanks for your effort already [14:30] fwereade_: how about this for an API in common to both the machine and unit agent? http://paste.ubuntu.com/5925443/ [14:31] rogpeppe, LGTM [14:31] fwereade_: thanks === tasdomas is now known as tasdomas_afk [15:03] rogpeppe, are you likely to be implementing a state.Agent interface roughly matching that? because I find myself heading in a very similar dirction, I think [15:04] fwereade_: i've just done the front end bits. i'm just about to do the server side. [15:04] fwereade_: i'm not sure quite what you mean by the state.Agent interface [15:04] rogpeppe, as Authenticator, Remover, Lifer, whatever [15:05] rogpeppe, ISTM that making unit and machine's agenty methods accessible via a State.Agent() call using state.entity() would fit nicely [15:05] fwereade_: perhaps. i'm not sure. [15:05] fwereade_: i thought i might do Jobs as a special case [15:05] fwereade_: as it doesn't really make sense to implement Unit.Jobs [15:06] fwereade_: the other methods aren't really Agent - they're *used* by the agent API, which i think is a bit of a different thing [15:06] rogpeppe, fwiw I think that "a unit is an agent with just one job" is quite a neat model [15:06] fwereade_: i considered it, but i don't think it helps much [15:07] rogpeppe, and remeber this isn't about how the API looks, it's about how it's convenient to present state to the API layer for clarity/convenience [15:07] fwereade_: it makes the unit agent code more complex (what's the point of having a Jobs method that you don't consult?) [15:07] rogpeppe, it eliminates the distinction between machine and unit agent [15:08] fwereade_: ah, is that your intention? [15:08] rogpeppe, except we're talking about different things still [15:08] rogpeppe, long-term, maybe [15:08] rogpeppe, but the jobs thing seems like the biggest issue [15:08] fwereade_: it seems pretty trivial to me [15:08] fwereade_: i'd just put a dynamic type check in the Job API entry point [15:09] rogpeppe, indeed, and so "an agent is a thing that runs jobs on behalf of some entity" becomes an nice clear accurate explanation [15:09] s/Job/Jobs [15:09] fwereade_: i like the fact that the unit agent code is simpler than the machine agent code [15:09] fwereade_: because it doesn't need to inspect dynamic jobs to run [15:10] rogpeppe, but the thing I'm thinking about today is state.Agent, which would have a whole bunch of methods used by various bits of the api, eg uniter machiner upgrader [15:11] rogpeppe, if that's not on your mind then all the better, we won't collide and you can see if you like it when I propose ;) [15:11] fwereade_: i think it's probably better to have separate interfaces for each piece of the API [15:12] fwereade_: rather than one agent interface to rule them all [15:12] fwereade_: tbh i'd prefer it if each of those interfaces was defined in the respective API server package [15:12] fwereade_: rather than in state [15:12] fwereade_: i think that matches Go's post-hoc interface definition idiom better [15:12] rogpeppe, I am not talking about the interfaces exposed by the API, I am talking about the interfaces exposed *to* the API [15:13] fwereade_: that's what i'm talking about too [15:14] fwereade_: i don't think the state package should need to second-guess the interfaces needed by the APIs built on top of it [15:14] rogpeppe, in my mind, it's not second-guess, it's responding to clear need [15:15] fwereade_: it's unnecessary - each of those API packages can define their own interface to abstract out the relevant parts of the state package [15:15] fwereade_: AFAICS [15:17] fwereade_: of course, state needs to define interfaces when it actually returns those interfaces (e.g. Lifer), but i'm not sure that it needs to know about Agent, for example. that seems like something built on top of it, at a different level. [15:17] fwereade_: but i'm interested to hear your take on it too [15:18] rogpeppe, I dunno, I think that the agent concept is already more than a little embedded in state [15:18] rogpeppe, AgentTools [15:18] rogpeppe, SetAganetAlive [15:18] er whatever [15:18] fwereade_: yes, there are bits and pieces [15:19] rogpeppe, I think that collecting them together will actually be pretty clear [15:19] fwereade_: as is necessary - those are pieces of agent-specific state [15:19] fwereade_: calling the interface "Agent" is wrong though [15:19] fwereade_: perhaps AgentEntity [15:20] but i don't like that either [15:20] rogpeppe, like LiferEntity and UAuthenticatorEntoty today, you mean ;p [15:20] god my typing is shot today [15:20] fwereade_: you started to remind me of an ex-coworker who had notoriously bad typing :-) [15:21] fwereade_: Lifer defines an object with a Life method [15:22] fwereade_: Authenticator defines an object with authentication methods [15:22] fwereade_: Agent would *not* define an object with agent methods [15:22] fwereade_: but it would simply have some methods that happen to be used by agents [15:22] fwereade_: and i don't really see why that interface should be defined in state itself. [15:23] fwereade_: in general we don't predefine all possible interfaces in Go, but leave it up to the client code to do that. [15:23] rogpeppe, the distinction between "agent methods" and "methods that happen to be used by agents" does not seem to me to present an overwhelming practical difference [15:24] rogpeppe, ISTM that if we do that we end up with the funky downcasting we already have in apiserver [15:24] fwereade_: they're totally different. an agent method would be something like MachineAgent.Run. [15:24] rogpeppe, "meh, everything we're calling here will have hat method, let's just use a Lifer" [15:25] rogpeppe, what we're getting kinda needs to be defined at the state level [15:25] rogpeppe, lots of little interfaces make sense where overlap is limited [15:25] rogpeppe, bigger interfaces also make sense where there's a lot of overlap, I think [15:26] rogpeppe, *even if* and given client of an Agent uses only one or two methods on it [15:26] s/and/any/ [15:27] rogpeppe, anyway, I'm going to go and see if the plan comes off coherently anyway ;p [15:27] rogpeppe, cheers [15:27] fwereade_, rogpeppe: https://codereview.appspot.com/12034043 - names package [15:27] fwereade_: ok [15:28] a lot of files are changed, but most changes are just renames [15:29] dimitern: i think i'd put all the code into one file in names - i don't think the sizes are big enough to justify the separate files, and i'd find it easier to read like that. [15:30] rogpeppe: i could do that, but I think separation is a good thing [15:30] dimitern: why so? [15:30] dimitern: i don't see that it helps anything really [15:31] dimitern: other than meaning i need to flip back and forth to see what things are referring to [15:31] rogpeppe: we could expand it later to include more stuff [15:31] dimitern: we could split it into multiple files as appropriate if that happens [15:31] dimitern: i find it much easier to see the whole lot on a single page [15:31] rogpeppe: then check LP's diff :) [15:32] dimitern: what about it? [15:32] rogpeppe: but seriously, I'm not insiting on it staying like this - fwereade_ what do you think? [15:33] dimitern: if nothing else, the related constants should go into the relevant files. [15:33] rogpeppe: this makes more sense to me, ok [15:33] dimitern, rogpeppe: I rather liked the bite-size nature of those files [15:34] dimitern, rogpeppe: well, maybe, having all the constants in one place also has its benefits [15:34] fwereade_: really? [15:34] dimitern, rogpeppe: I found it very easy to absorb that package as it was [15:34] rogpeppe: once it lands, using godef to jump to each definition is trivial [15:34] fwereade_: i found myself flipping back and forth between constant and code [15:35] dimitern, rogpeppe: the conceptual dividing lines are clear, and the simplicity of each chunk is also pretty clear IMO [15:35] fwereade_, dimitern: constants.go blurs the conceptual dividing line [15:35]