[00:48] <lifeless> blr: tdd = developing by bouncing off the rails
[00:48] <lifeless> blr: I *love* that quote [for all that I also love tdd]
[01:01] <blr> heh yes
[10:18] <cjwatson_> wgrant: I think I'm up to date with your reviews now.
[10:25] <wgrant> cjwatson_: Thanks.
[10:27] <wgrant> cjwatson_: I went back and forth between doing the unicode case in the xref layer and not.
[10:28] <wgrant> cjwatson_: We could certainly cast on the way in, but how would it work on the way out?
[10:28] <wgrant> In findFromMany, would we magically turn anything that looked like an int into an int?
[10:29] <wgrant> I expect it will eventually be covered by an intermediate layer that knows how to resolve LP DB objects.
[10:29] <wgrant> For example, if we had a type which used a name as a key, what would happen if the name looked integral?
[10:30] <wgrant> I'd query for [('project', 'foo'), ('project', '123')], and get [('project', 'foo'), ('project', 123)] back and crash with a KeyError.
[10:44] <cjwatson_> wgrant: True, that would be problematic.
[16:10] <cjwatson> well, after spending most of a day on it, I think I now have parallel testing working (vivid host, precise guest)
[16:13] <cjwatson> things I had to do: https://github.com/lxc/lxc/pull/667; use venv with testrepository 0.0.14, since newer versions expect subunit v2 and we aren't emitting that yet; https://code.launchpad.net/~cjwatson/launchpad/testrunner-uuid/+merge/272942; minor fiddling with .testr.conf; install python-gi and dbus-x11 in base container to make html5browser happier
[22:06] <lifeless> cjwatson: you can use subunit1to2
[22:07] <lifeless> cjwatson: to get v2 into newer testr's
[22:16] <cjwatson> I have a working solution now though :)
[22:16] <cjwatson> I think I would rather it continue to be a little bit inconvenient (but not too much) for me to use v1 locally, because in that case there's at least a chance I'll get round to hiking us up to v3
[22:17] <cjwatson> er, v2
[22:49] <lifeless> cjwatson: your call :)
[22:50] <cjwatson> Probably need to get better dev control of buildbot first though
[22:55] <lifeless> cjwatson: I just wouldn't want you to miss out on shiny new testr features
[22:56] <lifeless> cjwatson: e.g. https://rbtcollins.wordpress.com/2015/09/18/testrepository-roadmap-201516/
[22:57] <cjwatson> certainly don't want to be held back forever, but we see occasional reliability problems due I think to being on subunit v1, so that's some kind of priority in its own right
[22:57] <cjwatson> alleged buildbot passes with failed tests and a low test count are particularly worrisome
[22:58] <lifeless> what testr version are you using ?
[22:58] <lifeless> (on buildbot)
[22:59] <cjwatson> I don't think I know for sure, but I believe it's precise's, which is 0.0.5
[22:59] <lifeless> ok so
[23:00] <cjwatson> could be the one in https://code.launchpad.net/~yellow/+archive/ubuntu/ppa
[23:00] <lifeless> I think (set -o pipefail; existing_command | subunit1to2) and a testr build including 83dff0a51b3ed3f66d5c5f2313c5057234312663
[23:00] <lifeless> should fix that for you
[23:01] <cjwatson> ok, that may be worth trying out, thanks.  would need to hunt down exactly what version we're using
[23:03] <lifeless> that was fixed by 0.0.8 (perhaps earlier, but def 0.0.8)
[23:03] <cjwatson> what I really want to do is to convert buildbot into a juju-deployed thing on the new developer-managed stagingstack, for multiple reasons: (a) direct access so that we can see just what's going on with these kinds of problems (b) way easier to upgrade (c) brownie points for jujuifying stuff (d) could very likely distribute builds across workers on multiple compute nodes rather than needing a couple of enormous ones
[23:03] <lifeless> cjwatson: testr has hooks for distributing work itself now
[23:04] <cjwatson> there'll be a bit of a cost to syncing the tree out to remote workers but not a prohibitive one
[23:04] <cjwatson> ah, cool
[23:04] <lifeless> cjwatson: but you could also schedule the work yourself and use testr load to coalesce the results
[23:05] <lifeless> cjwatson: https://rbtcollins.wordpress.com/2013/01/14/multi-machine-parallel-testing-of-nova-with-testrepository/ shows one approach
[23:06] <cjwatson> I think it would be sufficient to prepare the workers before calling testr and then just have a suitable test_command
[23:07] <lifeless> yes; testr's current setup glue for this is serialised, so probably want a hybrid approach
[23:07] <cjwatson> right, a bit like that approach but for the time being with manual provisioning/cleanup
[23:09] <lifeless> the next gen stuff (see the roadmap blog post) will want more visibility, and that should enable really tuned things like optimising dispatch of per-layer things
[23:56] <wgrant> cjwatson: Oh, you're sharing a non-COW working tree between concurrent test runs? Ambitious.
[23:57] <wgrant> But yes, your buildbot plan roughly matches mine.