[00:49] wallyworld_: fyi: https://github.com/wallyworld/juju/pull/4 === kadams54-away is now known as kadams54 [01:08] katco: ta, looking, was talking to mr horatio [01:08] wallyworld_: no rush [01:08] axw: also ^^^^^^ [01:14] cool, will look after standup === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54_ is now known as kadams54-away [03:31] wallyworld_: your latest push to storage-get appears to have lots of unrelated changes [03:32] ehh.. but it's submitted [03:32] axw: i rebased and pushed and now the diff shows all the commits prior [03:32] the commits it shows were those to master from the time i branched to now [03:32] wallyworld_: are you reusing that because you're doing a PR to the feature branch? [03:33] yeah, i wanted to commit to both master and feature branch. but i had to rebase because of the uniter facade changes [03:33] both master and featuure branch now have storage get [03:33] mk [03:33] cool [03:33] the diff is noisy, but the code is good [03:34] without the rebase, there were conflicts [03:34] and i wanted to resolves those now, early === kadams54-away is now known as kadams54_ [04:09] wallyworld_: can you get quassel to highlight when there's unread notifications? [04:09] I mean, when you have quassel minimised [04:09] um [04:09] the little white arrow goes blue [04:09] xchat overlays on the icon with the number of unread notifications [04:09] on the unity launcher [04:09] huh, I don't see anything like that [04:10] i don't *think* quassel has unity integration ootb [04:10] so on my unity launcher icon [04:10] there's a little white triangle to the left, representing how many open instances there are [04:10] this is for any programme [04:10] for quassell, that triangle goes blue [04:10] when there's a notification [04:11] wallyworld_: can you please mention my nick in 30s? [04:11] maybe there's a unity plugin, not sure [04:11] sure [04:11] axw: you are awesome [04:11] wallyworld_: ;p [04:11] thanks [04:11] did it work? [04:11] it's very difficult to see the difference on my monitor :( [04:12] ah [04:12] teeny weeny little arrow [04:12] maybe you canuse unity tweak tool to change the colour [04:12] will take a look, thanks [04:12] i would also love better integration [04:20] axw: wallyworld_: u r both awesome :D [04:26] wallyworld_: https://github.com/wallyworld/juju/pull/7 [04:26] wallyworld_: all tests pass locally [04:26] looking [04:32] wallyworld_: I think we should change storage-get to be a bit more like relation-get, and pass the storage instance ID in as a flag [04:32] wallyworld_: which defaults to the hook.Info's StorageId [04:32] axw: hey i have to get to bed pretty quick, but i wanted to get some clarification while you're on. got a sec? [04:33] axw: sure, sounds reasonable [04:33] katco: certainly [04:33] axw: ty :) if the devices aren't necessarily created in the same session, where should the volume id's be persisted? [04:35] katco: volume IDs will be stored in state. we need to map them back to the volumes without relying on in-process state. if you had to you could create a local file to persist state (since it's all bound to the one machine anyway), but I think we might be able to just get away with encoding information in the volume ID [04:36] katco: namely, the loop device name, /dev/loopN [04:36] axw: ah i see. is that considered a temp. work-around, or can that really supplant storage in state? [04:37] (i.e. what should i work towards?) [04:37] axw: the WatchStorageInstances api can be moved to the v2 uniter facade [04:38] s/can/should [04:38] katco: whatever you can do to make it stateless (process-wise) is fine. I'd prefer if we encode info in the volume ID if possible [04:38] now that we have that facade [04:38] wallyworld_: can I just do that when it comes to merging with trunk? there's going to be lots of changes anyway [04:38] axw: okie doke, i'll try that. gives me something to go on for tomorrow [04:38] katco: cheers [04:39] axw: wallyworld_ anastasiamac goodnight tanzanite. have a great rest of the day [04:39] good night [04:39] and good night to everyone else as well :) [04:39] katco: u 2! c u soon :D [04:43] axw: + StorageIds set.Strings `yaml:"storage-ids,omitempty"` <- we were going with a single storage id per hook right? [04:45] axw: ah ffs, my connection dropped, did you see any of my stuff recently? [04:45] wallyworld: I saw your message about storage-ids [04:45] wallyworld: was about to reply :) [04:45] ah good [04:46] wallyworld: that is state for recording which storage instances have changed; we cycle through them firing off storage-X hooks for them individually [04:46] ah right ok [04:46] my uniter foo is not very good [04:47] axw: pr looks ok to me (but william should really comment). question save me checking code - is the storage watcher implementation based on our standard patterns for watchers used previously? [04:48] wallyworld: I think so? that's also going to change [04:48] wallyworld: it's currently watching storage instances, it should be watching attachments [04:48] agreed [04:49] wallyworld: this is not meant to be quality, just enough to work [04:49] yep :-) [04:49] merge it i reckon [04:49] wallyworld: thanks. you'll need to, I don't have write access [04:50] ah balls, i'll see if i can change that [04:50] wallyworld: it's your user, you probably don't want to do that [04:50] well, i was going to trust you guys :-) [04:50] i thouh i could enable write acess to a branch only [04:50] I wouldn't trust me not to break it :) [04:51] but merged now anyway [04:51] thanks [04:51] i almost expect breakages atm [05:02] waigani: here's the apiserver change that is required avoid the panics I was seeing with multi-envs [05:02] http://reviews.vapour.ws/r/808/ [05:03] menn0: swap you: http://reviews.vapour.ws/r/805/ [05:04] waigani: looking [05:06] waigani: Ship It (just one non-issue comment) [05:08] menn0: thanks, reading through yours. I haven't worked with connecting/closing an API connection before - so I may be learning more than reviewing [05:09] waigani: leave it if you were planning on finishing up, or if the review is too much of a distraction from what you're supposed to be doing [05:10] waigani: I'm about to finish up now anyway [05:10] menn0: okay, can we talk over the presence watcher tomorrow? [05:10] waigani: and Tim's best placed to review that PR. it's changing some stuff he implemented. [05:10] waigani: sure [05:11] menn0: I've started reading it, so I might just finish for my own benefit if no one elses [05:12] waigani: k thanks [05:12] waigani: well I'm off. see you tomorrow [05:12] menn0: night [05:16] axw: free for a chat? [05:31] wallyworld: sorry, eating [05:31] soon [05:31] sure, no hurry [05:35] wallyworld: see you in 1:1 [05:42] of course - feel very special :D [05:43] lol, anastasiamac typed into the wrong window :-) [07:54] wallyworld_: so I'm quite close to getting the hooks working... then it just dawned on me that using the subordinate isn't going to work until we have dynamic storage working [07:54] wallyworld_: subordinates don't get deployed until after the machine is started [07:54] ah balls, yes [07:55] axw: i just put up a pr https://github.com/wallyworld/juju/pull/8 [07:55] we'll have to think of a different way to demo [07:55] wallyworld_: looking [07:56] wallyworld_: yep. I'll take a look at the cassandra charm, it looked pretty easily to modify too [07:56] \o/ [07:56] tho I think it might've wanted filesystems not block devices .. [07:56] hmmm [07:56] once this current work lands, we can hook up again to agree what needs doing next [08:04] wallyworld_: reviewed [08:04] you've been busy :) [08:05] axw: yeah, wish i was just focussed on storage [08:05] thanks fr review [08:07] wallyworld_: cassandra wants fs. I'm going to look how much is involved in changing ceph-osd, and how demonstrable it is [08:08] ok [08:16] fwereade: how goes? [08:36] jam, hmm, not bad, I'm a bit blocked on How To Do Something Right at the moment, but I'll get there :) how about you? [09:03] wallyworld_: are you seeing a lot of messages about be leaving and rejoining? [09:03] I set up a proxy server, and I'm trying to figure out if it is spamming you guys, or just me. (my internet seems to kill SSL connections every 5-10 minutes for some reason.) [09:04] jam: nope [09:05] axw: thanks. So the proxy is working as I had hoped. [09:08] jam: there's a kernel bug that keeps killing my network card :-( [09:08] wallyworld_: ouch [09:08] only solution is to reboot [09:08] happens randomly and sometimes a lot, sometime a little [09:08] atm, it's a lot :-( [09:09] apparently it is scaring waigani and dimitern as well :) [09:11] jam, wow what's that? :) [09:11] dimitern: just that alot of people are bouncing on IRC [09:13] jam, ah, well I haven't noticed affecting me as much [09:33] wallyworld_, there's no useful info about bug 1413910 btw [09:33] Bug #1413910: 1.21-rc1: Ambiguous resolution of private-address

[09:33] oh, that's sad. i didn't look too closely [09:33] wallyworld_, no logs etc. who should I ask for more details? [09:33] :) [09:34] jamespage, can you provide more info about that bug please? ^^ [09:34] ask on the bug, or ping james directly [09:35] wallyworld_, cheers, sorry for the grumpiness - i've just had my coffee [09:35] dimitern: what? i didn't notice anything wrong :-) [09:35] i just appreciated that look looked at it [09:36] wallyworld_, :) ok, np - will try to figure out what's wrong [09:36] thanks :-) i can get involved a bit tomorrow or next day if needed [09:38] ok, cool [09:40] axw: i updated the pr to add pool validation in the constraints validation method, plus unified the pool creation [09:41] also unexposed the config translation [09:41] wallyworld_: cool, thanks [09:42] dimitern, sure [09:42] I can repro that easily [09:44] dimitern, in the specific case, the instance has multiple network interfaces onto the same openstack network [09:44] dimitern, juju appears to switch which ip address is the one associated with 'unit-get private-address' [09:50] dimitern, ok - so how do I get a 1.21 environment running now? [09:51] I can do 1.20 and 1.22-beta1 [09:53] jamespage: 1.21 should be in trusty proposed [09:53] https://launchpad.net/~juju/+archive/proposed [09:59] wallyworld_, ta [10:02] jamespage, thanks for the update, however I'd appreciate to look at some logs if possible [10:04] dimitern, working on that for you now [10:11] wallyworld_: cool, thanks [10:11] oops [10:11] ignore :) [10:11] ok [10:12] wallyworld_: I've had to fix a bunch of stuff to do with the uniter, get the Location set on storage instances, and have made some more tweaks to storage-get [10:12] slow going, but nearly there I think [10:13] great, i can review when done [10:13] i was pondering the dirty hack to get loop devices provisioned [10:18] dimitern, now I can't reproduce... [10:18] gah [10:19] axw: the spec says each env provider has a default block device source, and cites EBS volumes for AWS. that still needs to be done. and even if there's a default block device source registered, if that fails to provision, i wonder if loop on rootfs should be used in an emergency [10:20] wallyworld_: I'd rather defer any plans around fallback, it gets messy very quickly [10:20] we should be retrying if it fails [10:21] ok, but i can reasonably implement default block device sources [10:21] wallyworld_: yes, that would be great [10:21] so EBS for AWS, loop for local [10:21] that will do for now for the demo [10:21] wallyworld_: yup. magnetic ebs specifically [10:22] yep [10:22] well, the "ebs" pool doesn't specify volume type [10:22] "ebs-ssd" does [10:22] perhaps i should add explicit volume type [10:22] to the "ebs" pool [10:23] wallyworld_: maybe, though the default is magnetic if unspecified. [10:23] that will do [10:26] jamespage, ok, please let me know if you manage to repro it [10:27] dimitern, marked the bug invalid - I've tried three different ways with no luck [10:28] jamespage, cheers! [11:37] axw: here's the default pool implementation https://github.com/wallyworld/juju/pull/9 [11:52] dimitern: https://github.com/dimitern/juju/pull/6 [12:06] wallyworld_: having dinner, will bbl to take a look [12:07] axw: no hurry at all [12:07] just letting you know [12:20] wallyworld_: LGTM [12:21] ty, will look [12:21] wallyworld_: I hit a snag with Ceph earlier :/ it wants me to reboot the server before the disks can be used [12:21] which I don't think will go down well with EC2 [12:21] oh joy [12:21] sounds pretty dumb [12:22] wallyworld_: I haven't finished looking into it, it may be something I can work around [12:22] wallyworld_: otherwise I can try to hack the FS mounting code tomorrow [12:22] let's hope so [12:23] so we can use Cassandra or something else [12:23] FS would be great, as then we could look at the transcode charm [12:23] well, shared is needed [12:23] no, that needs shared... [12:23] yeah [12:23] shared needs a model change [12:23] might be able to hack something up though [12:23] maybe, I'll ponder [12:24] even if it's not properly modelled as shared and the charms are just given a different mount point [12:24] anyways, got to get the basics working first [12:42] morning [12:56] perrito666: o/ === lazyPower is now known as lazyPower|Travel [15:07] any mess folks around? [15:15] looks like its still pretty raw.. getting panics calling out to create [15:15] * hazmat moves on [16:24] are people still working on the action specs? [16:25] * hazmat scans prs and finds one [16:39] hazmat: they've been landing/etc and have a demo charm setup https://github.com/binary132/actions-demo [16:40] rick_h_, cool, just concerned with the api oddities on it [16:41] hazmat: yea, raise hell now as it's in feature frozen 1.22 I believe that had a beta go out today? /me had too much email today [16:41] http://pastebin.ubuntu.com/9900769/ [16:42] type: object .. wierd nesting of parameters [16:42] hi githubbers, is it possible to attach a file to a github issue? Or just images? [16:42] ahasenack: drag/drop it and see? I think it does but can't recall [16:43] rick_h_: " Unfortunately, we don't support that file type. Try again with a PNG, GIF, or JPG. " [16:43] ahasenack, not really. images.. or typically link to gist link for text [16:43] ahasenack: :( [16:44] hazmat: thanks === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [18:00] i'd appreciate it if someone could review this godeps change (and preferably QA it), because it runs some risk of killing all the CI bots... https://codereview.appspot.com/197110043 [18:01] wallyworld_: perhaps you might want to take look? [18:02] sinzui, mgz: you also, i suspect, use godeps a fair amount. i'd be interested in your take on it [18:02] rogpeppe, interesting. I just wrote something like that for testing [18:03] sinzui: i've been looking for some solution in this space for a while, as we've got a bunch of projects with different dependencies files [18:04] sinzui: please have a play with it and see if it this feature can meet your needs in this area [18:04] your rules look similar to mine. including the warning on conflict [18:07] sinzui: that's a good sign :) [18:13] sinzui: i'm considering a rule (perhaps optionally enabled) to consider also the version of the project in which each dependency file lives as a dependency [18:15] sinzui: i *think* that might make intuitive sense [18:15] rogpeppe, yes, that is challenging. I was thinking the same to ensure we aren't errantly mixing versions [18:15] I am writing up my use case in my thanks for your changes. [18:16] sinzui: the way i was considering doing it was to implicitly insert a dependencies.tsv file after each one explicitly specified, holding the project info for the previous dependencies.tsv [18:16] sinzui: that sounds useful, thanks [18:19] hazmat: about actions API - can you tell us more about your concerns? [18:21] hazmat: I know it looks ugly, but what you've pasted is an example of an action specification, which is essentially arbitrary - at the charmers discretion [18:24] jw4, the presentation is completely inane and that's not charmers, thats the api [18:24] hazmat: don't beat around the bush; how do you really feel? [18:24] hazmat: ;) [18:25] perrito666: you have an OSX machine, right? [18:25] jw4, why are properties nested under params.. everything else next to properties is effectively api garbage. [18:25] jw4, at a sibling level.. type: object, description duplicated, title, etc. [18:26] hazmat: what that result is depicting is a specification of the kinds of actions and associated parameters that the charm can perform [18:26] jw4, i know i'm in good company ;-) [18:26] jw4, i know what its describing [18:26] jw4, but the structure of that output is nonsensical [18:27] jw4, see how under ie. drop params, and bring properties up a level [18:27] hazmat: I see - I would love some help on improving it [18:27] jw4, everything else there under params besides properties is basically a leaky implementation or duplicate info [18:27] natefinch: I sort of do, my wife has [18:27] jw4, also default around most apis is capital 'Results' [18:28] there's massive api consistency.. but fixing each bit helps [18:28] hazmat: sure.. I know this is a bit of a big ask, but would you be willing to mock up an example of how you think it should look? [18:29] hazmat: I know we've already simplified bits of this by getting rid of duplicate or redundant info [18:29] hazmat: but an example of what you'd like to see would help if you have a bit of time [18:30] perrito666: ok, no big deal. There's a bug about OSX, but it honestly probably doesn't require OSX to fix.... https://bugs.launchpad.net/juju-core/1.21/+bug/1414800 [18:30] Bug #1414800: OSX versionpanic: osVersion reported an error: unknown series

[18:30] hazmat: fwiw, the actual spec is pretty light on these kinds of details [18:31] jw4, re example [18:32] jw4, drop the existing params, bring propeties up and rename as params or config. [18:32] hazmat: +1 (I think we did that elsewhere already) [18:32] jw4, couldn't say i'm just running trunk from today. [18:33] sinzui: i'm done for the day now. thanks in advance for your comments on the review. [18:33] hazmat: when you mentioned capitalized Results are you referring to: {u'results': [ becoming {u'Results': [ [18:34] jw4, yes .. that's more consistent with the rest of the api if its capitalized 'Results' [18:34] hazmat: +1 [18:35] hazmat: I'll add a card to our kanban to fix this and bring it up with our team [18:35] jw4, cool, thanks [18:36] hazmat: I appreciate the feedback - please feel free to bring up anything else that looks inane :) [18:37] jw4, np, ... oh.. more thing.. client watch for actions completions.. polling is a bit silly, but that's additive not transformative. [18:38] ideally just injected into allwatcher which is what most clients use [18:38] hazmat: I see - we do have a card outstanding for updating the allwatcher [18:38] hazmat: thanks [18:39] jw4, thank you.. cheers [18:39] hazmat: cheers [19:13] hi sinzui [19:14] hi back [19:35] ok, well, time to go rake the roof while it's still light out. [19:35] backport of a fix for yosemite to 1.21 is here if anyone has time: http://reviews.vapour.ws/r/809/ [19:35] anastasiamac: ^^ [19:36] (super simple, luckily) [19:45] did he say rake the roof? [19:46] perrito666: lol [19:47] heh... when you get 3 feet of snow, it's best to get some of it off the roof (just about to go do it). There's a thing called a roof rake for this job... probably not necessary in your neck of the woods, perrito666 ;) Looks like this: http://www.homedepot.com/catalog/productImages/1000/66/6657ac9f-d400-4469-9f64-1d5957d8b873_1000.jpg [19:47] ok, going now :) [19:48] natefinch: nope, half of the roofs here are not even inclined [19:48] :p [19:48] I am a bit surprised there is no electrical gizmo to prevent that [19:54] anastasiamac: I noticed your 'laconic' comment yesterday, but didn't realize it was on my PR :) [19:55] anastasiamac: thanks for the review; I'll update === kadams54 is now known as kadams54-away [19:58] natefinch, I commented on your PR. I am not a reviewer so I don't mind if you ignore me === kadams54-away is now known as kadams54 [20:13] OCR PTAL : http://reviews.vapour.ws/r/801/ [20:13] ^^ Add 'running' status and start time to Actions === kadams54 is now known as kadams54-away [20:57] hazmat, not sure if you got an explanation, but the top-level values under the 'actions' key (Params and Description) are keys for Juju's usage, belonging to Juju's action schema type; the values under "Params" are a one-for-one JSON-Schema mapping which is used by the schema lib verbatim to enforce param typing [20:59] basically, the JSON-Schema may be used by the frontend, and Go clients, the worker, etc, can use the Juju type's values without having to dig into the JSON-Schema or check whether it has nested keys present, etc [20:59] bodie_, ah.. that helps explain type: object syntax, though not the redundancy exposed to users. Params would logically correspond to the params defined in actions.yaml.. [20:59] except they don't === kadams54-away is now known as kadams54 [21:00] right; that's a request from fwereade due to the fact that requiring it to be verbatim JSON-Schema causes the simplest (single depth) schemas to be overly complicated to write [21:00] the transform is specified on the docs site. I'm not a huge fan, but it does make the writing of simple actions cleaner [21:01] https://juju.ubuntu.com/docs/authors-charm-actions.html#params-transformation [21:01] bodie_, while jsonschema has some value (i'd love vocabs etc in charms).. as a one off its not clear because its different then everything else that defines configuration schemas in juju atm. [21:02] bodie_, interesting so actions allow for complex value outputs? [21:02] hazmat: fwiw, the requirement for using jsonschema was from sabdfl directly [21:02] yeah.... I think we were hoping to roll more things (config at least) over to use the same technique, but we definitely want refinement and clarification brought to bear on it [21:02] jw4, i recall [21:03] jw4, well now i do.. looking at the api output.. i was .. well unclear would be nice ;-) [21:04] bodie_, thanks [21:04] I think the ideal way to handle it in clients is actually to use the service JSON-Schema to define the UI [21:04] rick_h_, ^ this on your radar? [21:05] hazmat: reading backlog, otp sec [21:05] the other keys (Description at the moment) could be fleshed out to include other things, like revision, or whatever might be needed by Juju specifically [21:05] not sure if that helps clarify intent [21:06] and yeah, not totally certain those need to be exposed to the user, the redundancy is confusing [21:06] bodie_, it does.. but it only really works.. if the uis do adopt it on top of maintaining their existing interfaces ontop of config schemas, else its unclear [21:07] hazmat: yeah - the UI team has been somewhat involved and should be acquainted with the plans to use the JSON-Schema to build the UI [21:07] hazmat: we'll see if rick_h_ concurs ;-p [21:07] there's a JS lib that makes UIs out of JSON-Schemas [21:08] s/UIs/UI elements/ [21:08] jw4: bodie_ hazmat we had instruction to use https://github.com/jdorn/json-editor to build the actions UX from json-schema per sabdfl suggestion which we thought was good [21:08] anything that could be expressed in jsonschema we could build a UI around [21:08] rick_h_, did the subject come of up of retrofitting charm and env config with the same? [21:09] and it's a push for a standards based approach to data types across juju with the spearhead being actions as greenfield work [21:09] yes [21:09] cool, yeah.. this was capetown last year.. [21:09] the goal was to test and push through with actions with juju charm config being updated as a follow up [21:09] yep [21:09] it's been a requirement from the start and we've been down this road a few times of trying to ditch it, but it fails to take the longer term idea into practice [21:10] if it's not there, it needs super reasons and sabdfl sign-off imo [21:13] jw4: natefinch: u've pingd me at 5am. still 7am here -m taking kids to school. will look l8r :) [21:15] anastasiamac: nothing important - cheers [21:15] jw4: thnx :D [21:16] hazmat, just to make sure you saw, the basic transform here might help make more sense of what happens to actions.yaml [21:16] hazmat, https://juju.ubuntu.com/docs/authors-charm-actions.html#simple-yaml-transform-example [21:22] bodie_, noted.. although the other confusing bit is renaming parameters to properties and reusing params for something else.. maybe rename the top level params to schema [21:23] hazmat, yeah, I think that would likely more sense. TLDR: use the value of the "Params" key to interact with libs that use json-schema. [21:23] bodie_, ie the top level object under params is actually not a param its the action itself [21:23] http://pastebin.ubuntu.com/9900769/ [21:24] brb a sec [21:24] just a repost of previous for context [21:24] yeah.. meetings over here. [21:50] perrito666, wwitzel3, ericsnow: any of you guys have nothing to do tonight and happen to be free at 8:30pm eastern? There's a meeting with cloudbase, totally not mandatory, but if you happened to be available, it would be cool to have someone there, otherwise alexis will do it on her own (which she said is fine). [21:50] natefinch: unfortunately not [21:50] ericsnow: no problem... I wouldn't expect you to be free at 6:30 your time :) [21:51] ericsnow: I'm skipping out too, just figured I'd ask in case someone had a boring night in planned... pretty much never applicable for homes with kids. [22:04] perrito666: not the best picture, but here's the results of me "raking the roof": https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-xpa1/v/t35.0-12/10951050_10152991996797348_1941075273_o.jpg?oh=820150bca86087f75043727217b74699&oe=54CA916F&__gda__=1422491522_a043b88ea0ceb52a051d1f3f2aa89eba [22:19] thumper: quick review please: http://reviews.vapour.ws/r/808/ [22:19] * thumper looks [22:20] this is the apiserver state cleanup change we discussed yesterday [22:20] thumper: I just added some tests at anastasiamac's suggestion [22:20] ok [22:22] thumper: the thing that really slowed me down is that I didn't realise that sometimes the server is serving an apiRoot and other times it is serving an apiHandler. Kill and Clean had to be implemented on both. [22:22] nit: Clean vs CleanUp ? [22:22] menn0: thoughts? [22:23] thumper: I was trying to stick with the Go convention of *er interfaces [22:23] and Cleanuper sounds bad [22:23] fine with Cleaner and CleanUp [22:23] I don't like the 'er' always [22:23] it doesn't always fit [22:23] thumper: I thought you'd pick up on that :) [22:23] :) [22:24] thumper: I'll change it [22:24] although I agree that Cleanuper is dumb [22:24] thumper: CleanUp or Cleanup? [22:24] * thumper thinks [22:25] most our existing code uses Cleanup [22:26] so probably go with consistency [22:26] thumper: apparently "cleanup" is a word in American and Canadian English [22:26] http://grammarist.com/usage/cleanup-clean-up/ [22:26] thumper: so I think it's fine [22:26] I prefer Cleanup [22:26] ok [22:26] go with that [22:27] love this: Australian and New Zealand publications are inconsistent on the matter. [22:29]