| * thumper tries an experiment | 00:49 | |
| thumper | 519 files changed, 9517 insertions(+), 9259 deletions(-) | 00:51 |
|---|---|---|
| thumper | $ git diff master | wc -l | 00:51 |
| thumper | 65880 | 00:51 |
| thumper | just a small experiment | 00:51 |
| === fuzzy_ is now known as Ponyo | ||
| thumper | wallyworld_: you're on-call reviewer right? | 01:04 |
| wallyworld_ | yeah | 01:04 |
| wallyworld_ | but not if wc -l gives 65000+ lines | 01:06 |
| * thumper is struggling with something... | 01:13 | |
| thumper | wallyworld_: it was entirely mechanical | 01:21 |
| wallyworld_ | thumper: np, i have to run out to the bank for a bit, can look when i get back | 01:25 |
| axw | thumper: https://bugs.launchpad.net/juju-core/+bug/1395564 | 02:09 |
| mup | Bug #1395564: jujud constantly spews `juju.worker runner.go:219 exited "identity-file-writer": StateServingInfo not available and we need it` <juju-core:Triaged> <https://launchpad.net/bugs/1395564> | 02:09 |
| axw | thumper: is that worker meant to be on all machine agents, or just state servers? | 02:09 |
| thumper | axw: ah... well... that's interesting | 02:10 |
| thumper | hmm... | 02:10 |
| thumper | I think it should just be on state servers | 02:10 |
| thumper | bugger | 02:11 |
| thumper | at least I think that refactoring is only on master | 02:11 |
| thumper | and the 1.21 fix didn't have that | 02:11 |
| LinStatSDR | ke;;p | 02:16 |
| LinStatSDR | Hello* ... | 02:16 |
| thumper | o/ | 02:22 |
| LinStatSDR | Hi :) | 02:31 |
| wallyworld_ | thumper: where's this mega branch? | 04:20 |
| menn0 | axw, wallyworld_: why does State.AddCharm() not use transactions? | 04:35 |
| wallyworld_ | not sure off hand, i'll look at code | 04:35 |
| menn0 | axw, wallyworld_: it's the one of the few (only?) place that uses Insert in state | 04:36 |
| menn0 | axw, wallyworld_: and it seems like using a transaction would make it simpler and avoids a tiny race | 04:36 |
| wallyworld_ | menn0: at first look i have to agree. i suspect that code dates way back to the early days of the Go port | 04:37 |
| wallyworld_ | i think roger could shed more light on the reasoning there | 04:37 |
| menn0 | wallyworld_: np. I'll check with him. it just stuck out with some of the work i'm doing. | 04:38 |
| wallyworld_ | for sure, i can see why | 04:38 |
| wallyworld_ | i suspect hysterical reasons but would be curious to know | 04:38 |
| axw | I also don't know why | 04:39 |
| axw | fwereade_: FYI, http://reviews.vapour.ws/r/522/ | 05:11 |
| wallyworld_ | fwereade_: ping | 07:30 |
| fwereade_ | wallyworld_, morning | 07:30 |
| wallyworld_ | hey, morning to you | 07:30 |
| wallyworld_ | question | 07:30 |
| wallyworld_ | we currently store status in a separate status doc, with _id set to the global machine or unit key | 07:31 |
| wallyworld_ | if we now store status for unit agent as well | 07:31 |
| wallyworld_ | we'll need a global key of sorts for that | 07:31 |
| wallyworld_ | so do you think a prefex of "ua#" would work? | 07:32 |
| wallyworld_ | also service will get status in there too | 07:32 |
| dimitern | jam, morning | 07:32 |
| dimitern | jam, 1:1? | 07:32 |
| fwereade_ | wallyworld_, thinking | 07:32 |
| wallyworld_ | but there's already a global key for service | 07:32 |
| jam | yeah, dimitern, brt | 07:33 |
| wallyworld_ | we also currently have a big hidge podge of status "enums" shared across entities | 07:33 |
| fwereade_ | wallyworld_, yeah, we should separate those enums out | 07:34 |
| wallyworld_ | what's there could remain as machine status | 07:34 |
| fwereade_ | wallyworld_, not everything there applies to machines iirc | 07:34 |
| wallyworld_ | and new ones (sharing some of the same string values) used for units | 07:34 |
| wallyworld_ | right, will have to break them up | 07:35 |
| fwereade_ | wallyworld_, so globalKey-style is fine by me | 07:35 |
| fwereade_ | wallyworld_, ua# feels ratherwrong though | 07:35 |
| fwereade_ | wallyworld_, (1) the existing one is really the agent state already, remember | 07:35 |
| fwereade_ | wallyworld_, (2) "a" implying agent is going to be misleading as soon as we manage to consolidate the agents | 07:36 |
| wallyworld_ | yeah true | 07:36 |
| wallyworld_ | for (2) we need a migration anyway | 07:36 |
| fwereade_ | wallyworld_, suffix of #charm, or #runtime, or something? | 07:36 |
| fwereade_ | wallyworld_, well | 07:36 |
| wallyworld_ | could retain u# for agent status for now | 07:36 |
| wallyworld_ | so you mean u#3#charm | 07:37 |
| fwereade_ | wallyworld_, u#foo/3#charm, yeah | 07:37 |
| wallyworld_ | right | 07:37 |
| wallyworld_ | can do that | 07:37 |
| fwereade_ | wallyworld_, don't forget that even if they're all in one process the "agent state" is still going to be meaningful | 07:37 |
| fwereade_ | wallyworld_, just increasingly inaccurately named, because it's more like worker state | 07:38 |
| wallyworld_ | and will be shared for that machine across units | 07:38 |
| fwereade_ | wallyworld_, surely not | 07:38 |
| fwereade_ | wallyworld_, it is and pretty much always has been uniter state | 07:38 |
| wallyworld_ | for some things it will, like allocating etc | 07:38 |
| wallyworld_ | i've just starting digging so i'll keep going, thank for clarification on using global key concept | 07:40 |
| fwereade_ | wallyworld_, still don't think so? I'm quite inclined to have the uniter stay the only thing responsible for setting its own "agent" state | 07:40 |
| wallyworld_ | a lot of the code i'm reading is quite new to me; uniter is something i've managed to avoid in detail till now | 07:40 |
| fwereade_ | wallyworld_, lucky you | 07:41 |
| wallyworld_ | \o/ | 07:41 |
| fwereade_ | ;p | 07:41 |
| wallyworld_ | i did like the wip branch i looked at last week | 07:41 |
| wallyworld_ | to separate out operations i think from memory | 07:41 |
| fwereade_ | cool | 07:41 |
| wallyworld_ | i just want it all to be done NOW | 07:42 |
| wallyworld_ | :-) | 07:42 |
| fwereade_ | wallyworld_, I didn't get the time to hack on that I hoped for this w/e | 07:42 |
| fwereade_ | wallyworld_, *but* well honestly I *could* land it now and we'd still be better off than we were -- however I feel obliged to test the damn thing properly, and I kept getting distracted late last week and never built up the momentum | 07:42 |
| wallyworld_ | if what you have is incrementally better, and works, and is tested, i'd be inclided to land | 07:43 |
| wallyworld_ | so it doesn't bit rot etc | 07:43 |
| wallyworld_ | we've branched 1.21 now | 07:43 |
| wallyworld_ | so 1.22 is aways off | 07:43 |
| wallyworld_ | deliver early and often and all that | 07:43 |
| fwereade_ | wallyworld_, so the trouble is that it's tested as well as it was before | 07:46 |
| fwereade_ | wallyworld_, the new structure makes it clear just how shitty that was | 07:47 |
| fwereade_ | wallyworld_, and I've been adding tests in the wrong order so I don't have many useful incremental pieces :/ | 07:47 |
| wallyworld_ | fwereade_: if it compiles, it works right :-D | 07:47 |
| fwereade_ | wallyworld_, it passes the uniter_test tests too | 07:47 |
| wallyworld_ | i'd be inclined to get what you have landable before doing any more | 07:48 |
| fwereade_ | wallyworld_, with just one non-error-message-string change, which I think is a good one anyway, because we're now properly triggering an observer we always should have | 07:48 |
| fwereade_ | wallyworld_, yeah, I am actively avoiding *changes* | 07:48 |
| wallyworld_ | good :-) | 07:48 |
| * fwereade_ is very tempted to make today an "I'm not here, I'm working" day | 07:49 | |
| wallyworld_ | use what you have, that sounds like it's at least got equivalent tests to what's there, as a great basis for launching the next phase | 07:49 |
| wallyworld_ | go dark and make it happen :-) | 07:49 |
| fwereade_ | wallyworld_, yeah, sounds good | 07:53 |
| wallyworld_ | \o/ | 07:53 |
| axw | fuuuuuuuuu | 08:03 |
| axw | wallyworld_: I just realised that my intention to use UUID on top-level devices as an identifier will break horribly if a charm requests a raw device and creates a new filesystem on it... | 08:04 |
| * axw sighs heavily | 08:04 | |
| * wallyworld_ sighs too | 08:04 | |
| axw | I think that means we have to partition devices and only dish out the partitions | 08:04 |
| axw | maybe only if it doesn't have a serial number | 08:05 |
| wallyworld_ | needs a little thought for sure | 08:07 |
| wallyworld_ | axw: what devices wouldn't have a serial number? | 08:09 |
| axw | wallyworld_: non-physical ones | 08:10 |
| wallyworld_ | that i did not know | 08:10 |
| axw | wallyworld_: for example, on EC2 none of the disks have a serial number because Xen | 08:11 |
| axw | there the block device name is persistent though | 08:11 |
| wallyworld_ | maybe that's as good as and we just abstract a device unique identifier | 08:12 |
| axw | wallyworld_: problem is MAAS, where there's not necessarily a guarantee that the disk has a serial. i.e. if/when there's support for non-physically attached disks | 08:14 |
| axw | hence why I asked for UUID and not serial | 08:14 |
| axw | *if* there's a serial we'll populate it when we see it in the machine agent | 08:14 |
| wallyworld_ | hmmm. hopefully for even non physically attached disks there's some concept a uuid/serial/something_else_unique | 08:16 |
| TheMue | morning | 08:38 |
| voidspace | jam: dimitern: TheMue: grabbing coffee will be 2mins late to standup - sorry! | 09:55 |
| dimitern | voidspace, no worries | 09:56 |
| voidspace | back, just in time | 09:59 |
| mattyw | morning all | 10:00 |
| mattyw | dimitern, do you have a link to the design document about how the new juju commands will look? | 10:00 |
| mattyw | dimitern, (also, morning) | 10:00 |
| jam | voidspace: you inspired me to do the same | 10:01 |
| jam | TheMue: standup ? | 10:01 |
| TheMue | omw | 10:01 |
| dimitern | mattyw, morning :) | 10:01 |
| dimitern | mattyw, not off hand, but I'll try to find it | 10:02 |
| dimitern | mattyw, I can't find it unfortunately | 10:15 |
| mattyw | dimitern, I'll keep looking, do you know who was supposed to be working on it? | 10:15 |
| dimitern | mattyw, either onyx or tanzanite IIRC | 10:16 |
| voidspace | dimitern: finished 1-to-1, going for moar coffeez and then I'd love to chat | 10:48 |
| dimitern | voidspace, ok | 10:51 |
| voidspace | dimitern: does subnetDoc need an annotator? | 12:12 |
| dimitern | voidspace, I don't think so - we can add it later I think, if we need to manage subnets via the gui | 12:20 |
| voidspace | dimitern: cool, thanks | 12:23 |
| sinzui | dimitern, jam do you have a moment to review https://github.com/juju/juju/pull/1214 | 13:46 |
| dimitern | sinzui, looking | 13:54 |
| sinzui | dimitern, sorry, I set master as the merge target in that PR. I closed it | 14:27 |
| sinzui | dimitern, https://github.com/juju/juju/pull/1215 is to change the version of the 1.21 branch | 14:29 |
| dimitern | sinzui, ah, ok -that looks better :) | 14:33 |
| dimitern | sinzui, 1 typo, otherwise lgtm | 14:33 |
| === wwitzel3_ is now known as wwitzel3 | ||
| sinzui | dimitern, oops. making a change before my first cup of coffee seems impossible | 14:34 |
| dimitern | :) | 14:34 |
| sinzui | fix is push dimitern | 14:35 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1395331 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| dimitern | sinzui, thanks - good to merge | 14:59 |
| wwitzel3 | fwereade_: ping :) | 15:09 |
| natefinch | perrito666, wwitzel3: man you guys are late to standup ;) | 15:13 |
| alexisb | fwereade_, I am going to log on the hangout with FF one sec | 16:03 |
| natefinch | man, utopic has been hell on my browser. Fine in every other way... but you know, the browser is pretty important | 17:10 |
| ericsnow | could someone have a look at http://reviews.vapour.ws/r/526 | 17:19 |
| ericsnow | it's a one-liner that clears the current CI blocker | 17:19 |
| natefinch | ericsnow: looking | 17:21 |
| ericsnow | natefinch: thanks | 17:21 |
| ericsnow | the joy of having CI-only tests! | 17:22 |
| natefinch | ericsnow: ship it! | 17:23 |
| ericsnow | natefinch: thanks | 17:23 |
| LinStatSDR | Hello all. | 17:24 |
| natefinch | good afternoon | 17:26 |
| ericsnow | fwereade_: ping | 17:27 |
| === kadams54 is now known as kadams54-away | ||
| ericsnow | sorry for the pain of 1395331, folks | 17:59 |
| ericsnow | the fix is in but the CI tests have to cycle through now | 17:59 |
| jw4 | ericsnow: :) no worries tx | 17:59 |
| jw4 | do we need to wait for something before the CI gets opened again? The query on launchpad for critical bugs is returning 0 again, but CI is still rejecting | 18:00 |
| * jw4 feels so rejected | 18:00 | |
| ericsnow | I don't recall if CI automatically unblocks once certain tests pass or if it requires manual intervention | 18:01 |
| ericsnow | my vague recollection is of the former being the case, but mgz & co. would know | 18:02 |
| jw4 | wallyworld, sinzui who should I ask about when/how CI would be unblocked? | 18:03 |
| ericsnow | natefinch: was "Add juju-provider-zone to relation data" the task you recommended to me the other day? | 18:05 |
| sinzui | natefinch, ericsnow, jw4 We need to steal juju-ci to do reliability testing. I don't know when I can enable testing, or at least say the regression is fix released | 18:06 |
| natefinch | sinzui: this seems problematic if it means we can't land any code | 18:06 |
| ericsnow | sinzui: the failure is limited to the backup-restore tests (which exercise the plugins) | 18:07 |
| natefinch | jw4: I believe the answer in general is "once the CI tests that failed pass again, then the bug that was blocking CI is marked fix released, and *then* CI is officially unblocked" | 18:07 |
| jw4 | natefinch: I see - I was just querying launchpad for when there were 0 critical issues | 18:08 |
| ericsnow | sinzui, natefinch: if it makes it so we can simply unblock, I'd be glad to revert PR 1003 | 18:08 |
| ericsnow | natefinch: ah, right, "fix released" is the trigger for unblocking CI | 18:09 |
| natefinch | yep | 18:09 |
| sinzui | ericsnow, no don't | 18:09 |
| ericsnow | sinzui: k | 18:09 |
| sinzui | ericsnow, jw4, natefinch : I marked the bug as fix released, but it is untested. you are free to merge. Revision testing will resume when reliability testing comp;lete | 18:11 |
| jw4 | thanks sinzui | 18:11 |
| ericsnow | natefinch, sinzui: if restore supported local provider (which is currently *not* adviseable) then the CI backup-restore tests could be replaced with functional tests in the core suite, and this sort of situation (an undetected breakage of the backup CLI plugin) would be avoidable in the future | 18:13 |
| ericsnow | natefinch, sinzui: however that would require the "proper" local provider that we never seem to allocate time for writing | 18:14 |
| ericsnow | sinzui: thanks for unblocking that! | 18:14 |
| sinzui | ericsnow, The restore tests often fail because of juju timing issues and substrate api/network issues. I think we will always need a restore test in clouds to verify real world situations. Though it would be nice to not need to run the test with every revision | 18:17 |
| ericsnow | sinzui: good point | 18:17 |
| ericsnow | sinzui: both are needed then | 18:18 |
| ericsnow | natefinch: about "Add juju-provider-zone to relation data", was that the one? | 18:20 |
| natefinch | ericsnow: that one and adding zone to the unit-get hook | 18:28 |
| ericsnow | natefinch: k | 18:28 |
| ericsnow | natefinch: I'm adding task cards to leankit for some of the tasks | 18:28 |
| natefinch | ericsnow: cool | 18:29 |
| natefinch | ericsnow: feel free to adjust the estimates if you think they need adjusting. They're listed in ideal developer days, so like, if you got to code for 8 hours straight with no interruptions... I usually then double that for real-world workdays | 18:31 |
| ericsnow | natefinch: :) | 18:31 |
| natefinch | ericsnow: I suggest not reducing the estimates even if you think it'll be faster, though. We can always use the padding to make up for bad estimates elsewhere | 18:31 |
| ericsnow | natefinch: definitely | 18:32 |
| voidspace | g'night all | 18:39 |
| katco | hey does anyone have an ssh server you recommend for windows? a friend wants to run one on (i think) win7 | 18:56 |
| ericsnow | katco: I always ending up simply using cygwin | 18:58 |
| ericsnow | ("simply") | 18:59 |
| katco | ericsnow: yeah same here, but that may be too complicated for him | 18:59 |
| natefinch | it's so sad that this is actually a question that has to be asked | 19:00 |
| katco | i know... no clue why windows doesn't support ssh these days | 19:00 |
| katco | of course windows admins used to look at me funny when i asked how to get a command prompt remotely | 19:01 |
| natefinch | FWIW I think Cygwin is the work of the devil and would not recommend it to anyone I want to still like me in 6 months. | 19:01 |
| katco | lol it was a god-send when i was trapped on windows @ work | 19:01 |
| katco | i would get a bash prompt and sign in relief :) | 19:01 |
| katco | grep, less, find! all my friends are here! | 19:02 |
| natefinch | I used it for 7 years at my last job... at least once every 6 months I would have to totally reinstall it because it would randomly f-up if I tried to update something | 19:02 |
| katco | wow really? | 19:02 |
| katco | i never had a problem | 19:02 |
| katco | used it probably for... 5 years? | 19:02 |
| natefinch | I don't know how often I had to do the POS rebaseall thing, which would work like 1/3rd of the time | 19:03 |
| katco | lol | 19:03 |
| natefinch | and it doesn't help that it defaults to updating EVERYTHING when you run it to update just one thing, which ends up being this massive download that only has a small chance of succeeding. | 19:04 |
| natefinch | ....I'm not bitter | 19:04 |
| katco | haha | 19:05 |
| natefinch | oh yeah, the kicker is that we were using cygwin to support our build infrastructure..... which built a .Net application and a Java application. (Yes, both would have built just fine on Windows without cygwin). | 19:05 |
| katco | i really never had any problems with it | 19:05 |
| jw4 | natefinch: was msys a viable alternative to cygwin in your situation? | 19:06 |
| natefinch | The only thing we actually needed cygwin for was to build RPMs for the java server part (sorry to say we deployed the server to CentOS) | 19:06 |
| natefinch | jw4: I have no idea. I tried to have as little to do with cygwin as possible. | 19:07 |
| jw4 | natefinch: yeah - I never really enjoyed cygwin, but msys usually seemed to meet my needs when on windows | 19:07 |
| katco | my stress level has gone down so much now that i get to work in ubuntu all day :) | 19:08 |
| katco | it's just cozy. | 19:08 |
| jw4 | katco: lol | 19:09 |
| jw4 | I cut my programming teeth in cross-platform unix | 19:10 |
| jw4 | but have been mostly doing .NET for the last decade | 19:10 |
| katco | i have much the same story | 19:10 |
| katco | i always used some form of *nix, and then got a job at a .NET shop | 19:10 |
| jw4 | when powershell came out it was like the hallelujah chorus | 19:10 |
| katco | liked the language, disliked the platform. | 19:10 |
| katco | (C#) | 19:10 |
| jw4 | yeah, I'd like to play more with F# too | 19:11 |
| katco | more-so because anything that _wasn't_ microsoft was some odd duck that we couldn't risk using (e.g. sqlite3, angular, jquery... etc.) | 19:11 |
| natefinch | heh. My company was a startup with a Java server on CentOS and big .Net desktop client. Can't tell you how often we had customers ask if Postgres was a reliable DB, and why we weren't using SQL Server. | 19:16 |
| jw4 | nice | 19:17 |
| natefinch | We got acquired by a big company that was 100% microsoft services, so when we started The Big Rewrite (because isn't there always one?) we were basically forced into a .Net webserver w/ SQLServer | 19:17 |
| natefinch | We at least were able to convince them that the server could use a REST API and not SOAP | 19:18 |
| jw4 | *whew* | 19:18 |
| jw4 | SOAP just needs to die | 19:18 |
| natefinch | "But you can just generate client code from the WSDL...." | 19:18 |
| natefinch | AAHHHHH | 19:19 |
| jw4 | haha | 19:19 |
| natefinch | At the time I was trying to push for it to be a single page web app using Angular or something similar, but that was too... modern... for them, so it ended up being all server-side rendering & jquery (oh except for the data for some graphs that would then get downloaded asynchronously for some reason). | 19:20 |
| jw4 | lol - did you get to use ASP.NET MVC at least? | 19:21 |
| natefinch | yes? IIRC... and Entity Framework, which was a huge pain in the butt and cemented my "ORMs are evil" beliefs | 19:22 |
| jw4 | EF has come a long way, but still can't overcome the fundamental impedance mismatch between relational data and object data | 19:22 |
| natefinch | and this was the optimal case where we're rebuilding from scratch, but have 100% perfect knowledge of the data domain and how we're going to store it... it's just that if you don't structure your data & tables perfectly, then things just don't work with very little feedback about why. And forget trying to do anything fancy, like storing data blobs... | 19:25 |
| alexisb | natefinch, I am going to be a little late | 20:26 |
| natefinch | alexisb: ok | 20:27 |
| natefinch | alexisb: np | 20:27 |
| alexisb | natefinch, ok on and ready when you are | 20:39 |
| thumper | ick... | 20:40 |
| natefinch | alexisb: coming | 20:40 |
| === kadams54 is now known as kadams54-away | ||
| bogdanteleaga | anyone has an idea why separating runnings tests with check.f=foo doesn't work if the bar_test.go file doesn't have a bar.go counterpart? | 20:54 |
| bogdanteleaga | or what other reasons there might be for it not working | 20:55 |
| thumper | bogdanteleaga: I think we need a little more context | 20:56 |
| thumper | bogdanteleaga: got your test file handy to pastebin? | 20:56 |
| bogdanteleaga | for example bench_test in core/state | 20:57 |
| bogdanteleaga | if I do check.f=BenchmarkSuite it says OK:0 passed | 20:57 |
| === kadams54-away is now known as kadams54 | ||
| thumper | bogdanteleaga: probably because the BenchmarkSuite is for benchmarking not testing? | 20:59 |
| bogdanteleaga | thumper: conn_test does the same thing | 21:00 |
| bogdanteleaga | thumper: and they were the only ones I've tried so far and they didn't have normal.go counterparts | 21:00 |
| thumper | gocheck.f ? | 21:00 |
| bogdanteleaga | thumper: but assign seems to work | 21:00 |
| bogdanteleaga | yes | 21:00 |
| thumper | you said `check.f` | 21:00 |
| natefinch | I think both work now... remember gocheck is now "check" | 21:00 |
| thumper | the filename has no impact | 21:01 |
| thumper | natefinch: really? | 21:01 |
| thumper | oh | 21:01 |
| bogdanteleaga | yeah, I've tried both | 21:01 |
| bogdanteleaga | gocheck seemed to work until I hit that problem | 21:01 |
| bogdanteleaga | then I tried check and that didn't work either | 21:01 |
| thumper | mramm2: call time | 21:04 |
| thumper | ? | 21:04 |
| === kadams54 is now known as kadams54-away | ||
| thumper | https://github.com/juju/testing/pull/40 anyone? | 22:34 |
| fwereade_ | thumper, LGTM | 22:46 |
| fwereade_ | thumper, feeling brave? I think you'll hate me but you'll like it in the end: reviews.vapour.ws/r/527/diff/ | 22:46 |
| fwereade_ | thumper, there are two files of tests that are just repeated `c.Fatalf("XXX")`, I wanted to finish those today but I'm too tired | 22:47 |
| fwereade_ | thumper, still I don't expect non-trivial non-test changes and I want to get some less-casual eyes on it | 22:48 |
| katco | wallyworld: guess what is defined in a main package and is not exportable at the moment =| | 22:52 |
| === fuzzy_ is now known as Ponyo | ||
| wallyworld | katco: ummm, not sure? | 23:05 |
| katco | wallyworld: MachineAgent | 23:05 |
| wallyworld | \o/ | 23:06 |
| katco | :) | 23:06 |
| wallyworld | the stuff in main should be thin anyway | 23:06 |
| wallyworld | so maybe a chance to refactor to fix it | 23:07 |
| katco | yeah i'll have to | 23:07 |
| wallyworld | luck you | 23:07 |
| katco | it's a good change anyhow... glad you suggested landing this separately | 23:07 |
| katco | and by suggested, i mean "commanded atop your iron throne of management" | 23:08 |
| wallyworld | katco: just saw this last comment as i was helping someone elsewhere | 23:33 |
| wallyworld | :-( | 23:33 |
| katco | it's ok, i understand you have a manager's schedule. | 23:33 |
| * katco pokes the open wound | 23:33 | |
| wallyworld | :-( :-( :-( | 23:33 |
| * katco now feels bad | 23:33 | |
| wallyworld | good | 23:33 |
| katco | haha | 23:33 |
| === kadams54 is now known as kadams54-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!