[00:22] <jelmer> lifeless: hi
[00:55] <poolie> hi igc, spiv, https://bugs.edge.launchpad.net/bzr/+bugs?field.tag=udd
[00:55] <poolie> hi all
[00:59] <igc> hi
[01:01] <jml> poolie, hi
[01:01] <poolie> hi there jml!
[01:01] <jml> poolie, you should unify some accounts: https://www.ohloh.net/search?q=martin+pool
[01:02] <poolie> oh ok
[01:02] <poolie> i did a bunch of them the other week
[01:02] <poolie> jml, when was that stakeholder meeting going to be?
[01:03] <jml> poolie, 21 June, 1800UTC
[01:03] <poolie> ok
[01:37] <poolie> igc, spiv, https://edge.launchpad.net/bzr/+milestone/2.2.0
[01:51] <poolie> https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-number_of_duplicates&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.importance:list=HIGH&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[01:51] <poolie> blah
[01:52] <poolie> which is high priority bugs by number of dupes
[01:53] <spm> new bug. LP needs shortly (cryptic) get request fields for sharing searches. Won't Somebody Think Of The IRC Channels!!!!
[01:53] <spm> shorter. even.
[01:58] <AfC1> Why does the Ubuntu package "bzr" depend on "bzrtools". Shouldn't that be "recommends" or something?
[02:00] <jelmer> AfC: it doesn't depend on bzrtools
[02:01] <jelmer> AfC: it's in the Recommends in the original debian package and as far as I can tell that hasn't been changed in ubuntu
[02:01] <AfC> Oh. Have I done something wrong, then? I just did "apt-get install bzr" on a (very) fresh system and it dragged in bzrtools. I was a bit surprised by that
[02:02] <poolie> i think apt is configured to install recommends by default
[02:02] <jelmer> AfC: apt-get installs Recommends by default these days
[02:02] <poolie> there's a way to change this-
[02:02] <AfC> ew
[02:02] <poolie> jelmer do you think https://bugs.edge.launchpad.net/bzr/+bug/481748 is now ready to implement based on the list discussion about revision specs in urls?
[02:04] <poolie> hm
[02:04] <jelmer> poolie: yeah, I think so. Though that'll also need some generic work on supporting extra arguments in URLs
[02:04] <poolie> it's a bit hard to find
[02:04] <jelmer> AfC: aptitude -R will ignore recommends
[02:04] <jelmer> I'm not sure if -R will work for apt-get
[02:09] <AfC> jelmer: thanks, will try that
[02:09] <AfC> brb
[02:15] <lifeless> jelmer: hi?
[02:16] <lifeless> jelmer: I'm back off out in a minute, perhaps more content than ping, and I'll reply when I get back :)
[02:17] <poolie> afc, you can set something in /etc if you want this permanently
[02:17] <poolie> cheerio lifeless
[06:00] <lifeless> hi poolie
[06:00] <lifeless> poolie: I think I have the same hardware issue you had
[06:01] <poolie> hi there!
[06:01] <lifeless> loose cpu heatsink
[06:01] <poolie> ah, really?
[06:01] <lifeless> my games machine is powering off frequently
[06:01] <poolie> after yours was posted across the tasman?
[06:01] <lifeless> yes
[06:01] <lifeless> :(
[06:01] <poolie> erk
[06:01] <lifeless> it was -very- occasionally doing it first
[06:01] <lifeless> and I've inspected the CPU heatsink, and one corner screw is loosish
[06:01] <poolie> i'm still waiting for the 2GB DDR3 to come in so i can get it rebuilt
[06:01] <poolie> mm mine were too
[06:01] <lifeless> its a twist-lock thing
[06:02] <poolie> and i just kind of shrugged
[06:02] <poolie> right
[06:02] <lifeless> but that one won't lock firmly
[06:02] <poolie> exactly
[06:02] <lifeless> yeah
[06:02] <lifeless> I'm going to take a little time tomorrow
[06:02] <lifeless> and drop this in to get addressed
[06:02] <lifeless> also
[06:02] <poolie> heh i just found in my office the other day one of the special torx keys to tighten an ia64 heat sink
[06:02] <lifeless> we've put an offer in on a house
[06:02] <poolie> _that_ won't come loose :)
[06:02] <poolie> congrats
[06:03] <spiv> Ooh :)
[06:03] <lifeless> so I need to do a little run around dance for that with lawyers, inspectors etc
[06:03] <StevenK> lifeless: Nice!
[06:03] <poolie> mm
[06:03] <poolie> so we had a look here into https://bugs.edge.launchpad.net/bzr/+bug/582157
[06:03] <poolie> without really reproducing it
[06:03] <lifeless> poolie: long story short - I'll be around on basically .au hours tomorow
[06:03] <poolie> istm there are two classes of problems here
[06:04] <poolie> ah you're not working so i won't bother you with it
[06:04] <lifeless> poolie: cool, thank you for pulling on the string
[06:04] <poolie> ok, np
[06:04] <lifeless> no, no bother
[06:04] <lifeless> its not like Canonical has traditional boundaries
[06:04] <poolie> ok so the two classes are: things where we know we're going slower than we should; and secondly things where we are unexpectedly slow
[06:04] <poolie> this bug would be in the second class
[06:05] <poolie> we have some ideas for shots in the dark that are probably useful anyhow, and for improving debuggability/supportability
[06:05] <lifeless> I can't wait for steams Linux port.
[06:05] <lifeless> one thing I thought of doing
[06:05] <lifeless> as a fairly immediately useful thing
[06:05] <poolie> after that, i'm going to put this back to incomplete
[06:05] <lifeless> was to make a per-invocation server side log
[06:06] <poolie> mm
[06:06] <poolie> so the ideas were
[06:06] <poolie> 1- use a socketpair to the ssh client, not a pipe
[06:06] <lifeless> that is, $ISO16whatever-$PID.log in ~/.local/bzr/ or some such
[06:06] <poolie> - not proven to fix this but a generally good idea; may alleviate poor blocking behaviour
[06:06] <poolie> ok
[06:06] <poolie> that's good too
[06:07] <lifeless> and then get that cherrypicked into LP production, add -Dhpss on the server side and get the logs synced every 5 minutes or so
[06:07] <poolie> 2- when TERM=spiv, server sends its hpss log over stderr so you can see on the client where it thinks it's spending time
[06:07] <lifeless> so we could see chunking, groupcompress stats etc
[06:07] <poolie> 3- log into that how much cpu time we spend per request
[06:07] <poolie> right
[06:07] <poolie> this would be quicker than getting it off lp via losas etc
[06:07] <lifeless> I like the idea of getting more data
[06:07] <lifeless> I think we should aim for getting more data all the time
[06:08] <poolie> 4- print a few more stats at the end: number of rpcs, number of ~mtu and <<mtu read() responses
[06:08] <lifeless> so that when someone says 'man it was slow this morning', we can see why
[06:08] <lifeless> that doesn't conflict with getting more in an immediate mode like you are describing
[06:08] <poolie> right
[06:10] <poolie> and i think that's it
[06:10] <lifeless> I agree that that bug should be used for 'lp is slower than bzr+ssh in general'
[06:11] <lifeless> I'm not sure where 'bzr+ssh around the world is slower than bzr+ssh locally' should go, if anywhere.
[06:11] <lifeless> [one theory about bzr+ssh performance is window choking on the tcp links - I was doing tcptrace analysis with spm a couple weeks back on this]
[06:11] <poolie> ah
[06:11] <poolie> that's possible
[06:12] <lifeless> on spm's recommendation I filed an RT ticket to increase the buffer limits on chokecherry or whatever the server is
[06:12] <poolie> crowberry?
[06:12] <lifeless> its in the lp queue if you want to dig it up
[06:12] <poolie> i wish the machine list page was up to date
[06:12] <lifeless> $suitablemachinename
[06:12] <poolie> and did you actually find anything from tcptrace?
[06:12] <poolie> i was just wondering if there was a machine like that
[06:12] <lifeless> was something a little suspicious, then PPing
[06:12] <lifeless> then looming
[06:13] <lifeless> that said, changing on crowberry live isn't the best place to test theories
[06:13] <poolie> using a socketpair may help there
[06:13] <poolie> right
[06:13] <lifeless> so we'll want to repurpose tungsten probably
[06:13] <lifeless> to be a testbed
[06:13] <poolie> something tcp related would be compatible with different people observing very different results
[06:13] <lifeless> I'm not sure why a socketpair would help
[06:14] <poolie> i think that they allow partial reads while a pipe does not
[06:14] <lifeless> interesting
[06:14] <poolie> imbw
[06:15] <poolie> oh the other possibility is that it's load-related on the server
[06:15] <lifeless> holy cow steam installs fast on SSD
[06:15] <lifeless> yes, load is a big concern
[06:15] <poolie> under windows?
[06:15] <lifeless> cedega
[06:16] <lifeless> more detailed logs would let us ascertain the concurrent bzr processes, and their activity, after the fact
[06:33] <StevenK> lifeless: What were your thoughts as bzr's TestCase as a fixture?
[06:33] <lifeless> *blink*
[06:36] <lifeless> StevenK: what do you mean
[06:38] <StevenK> lifeless: Context is your comment on this MP: https://code.edge.launchpad.net/~stevenk/launchpad/poppy-sftp-test-isolation/+merge/26717
[07:58] <vila> hi all
[08:03] <spm> hey vila!
[08:04] <vila> spm: _o/
[08:42] <thumper> what is the simplest way to get a time zone aware datetime object for the revision time?
[08:42] <thumper> a revision has a timestamp and timezone
[08:42] <thumper> is there a simple way?
[08:45] <vila> thumper: My memory may be a bit dusty, but I think I recall that the timezone and datetime should be supplied both or none of them
[08:45] <vila> thumper: so, short answer: no
[08:47] <thumper> is the timestamp of the revision in UTC or local time?
[08:49] <vila> gee, let me check, I'd say UTC, but I'm sure there are tests for that
[08:58] <vila> thumper: I was wrong, it's in local time (AFAICS)
[08:58] <thumper> vila: I think I'm going to agree with your first answer
[08:58] <thumper> vila: it is UTC
[08:59] <thumper> if I go: datetime.utcfromtimestamp(r.timestamp) it is right
[08:59] <thumper> where r is a revision object
[08:59] <vila> thumper: you checked that with a timezone != 0 ?
[08:59] <thumper> I'm not sure why a timezone is also recorded
[08:59] <thumper> r.timezone is 43200
[09:00] <thumper> hang on
[09:01] <vila> it's a shame it's not better documented anyway :-/
[09:02]  * thumper is a little frustrated
[09:02] <thumper> it seems to be UTC
[09:02] <thumper> even though a timezone is recorded
[09:06] <vila> hmm, so I looked at the wrong place and we may have bugs there..
[09:07] <vila> but looking at how log process that, yes, it seems to be UTC
[09:56] <sivang> hi
[09:56] <sivang> so, I have 2 branches who have diverged for some unclear reason.
[09:56] <sivang> nor merge or dif --old shows anythinig useful,
[09:57] <sivang> besides that my current branch is all extra to the push location - which was not like this before my laptop commit.
[09:57] <sivang> How to solve this?
[10:03] <jelmer> sivang: have you tried "bzr missing" ?
[10:03] <jelmer> that should tell you the revisions that are present in one branch but missing in the other
[10:07] <mwhudson> vila: when are you arriving in cambridge?
[10:08] <vila> mwhudson: tomorrow, around ~14h30 if all goes well
[10:08] <mwhudson> vila: ok
[10:28] <sivang> jelmer: I have, it suddenly shows me that all of the commits on the local branch I am working on are extras
[10:30] <parthm> mgz: thanks for the bzr-grep patches. i am going through no-match-fast path right now.
[10:41] <jelmer> sivang: that certainly explains why it's giving you that error
[10:49] <sivang> jelmer: right, but how is that that suddenly all those revision are extra?
[10:50] <sivang> jelmer: this wasn't so a day before.
[10:55] <sivang> jelmer: so it seems the only way to solve this is to rebranch
[10:57] <jelmer> sivang: Have you perhaps rebase your branch or something like that?
[11:01] <sivang> jelmer: not that I know of.
[11:01] <sivang> jelmer: This should be explicit enough for me to remember, from a bzr user POV
[11:01] <sivang> :)
[11:04] <sivang> jelmer: I'm rebranching, this takes too long to resolve with no apparent stuff to merg
[11:04] <sivang> jelmer: e.g. merge says there's nothing to do
[12:55] <C-S> ls
[13:15] <C-S> parthm: are you there?
[13:28] <parthm> C-S: hi
[14:16] <feckser> in .bzr/repository/indices I have many duplicate files.  Can I unlink or hard link them all?
[14:16] <feckser> and not break anything?
[15:16] <maxb> feckser: This should not be the case
[15:17] <maxb> feckser: I suggest pastebinning the output of 'ls -lR .bzr/repository/' so people here can understand the situation better
[15:21] <feckser> maxb: what should not be the case?  There should not be binary duplicate indices?
[15:21] <maxb> It's pretty unexpected, yes
[15:31] <feckser> http://www.pastey.net/137418-3kta
[15:54] <maxb> feckser: What? All your concern is about 4 60-byte files?
[15:54] <maxb> stop worrying
[15:54] <feckser> maxb: they obscure the duplicate list.
[15:55] <feckser> They make it harder to process removal of duplicates.
[15:55] <maxb> huh?!
[15:55] <feckser> When I perform a search for duplicates they are always returned.
[15:55] <maxb> So? Why does this bother you?
[15:56] <feckser> It makes the process of finding and removing unwanted duplicates harder
[15:57] <feckser> and that was only an example.  There are more in other bzr repositories.
[16:01] <maxb> Unless you can find duplicates of substantial size, I feel this is a non-issue
[16:23] <feckser> maxb: it is not just about finding duplicates in bzr repositories, it is about finding them all my files.
[16:24] <feckser> some of the directories under ~ are bzr repositories.
[16:24] <maxb> Make your dupefinder ignore .bzr then
[16:24] <feckser> inore list
[16:24] <feckser> it has no ignore list
[16:26] <maxb> Personally, I see no problem with Bazaar happening to produce identical byte content in a few small files as an implementation detail
[16:26] <feckser> I did not say it was a Bazaar problem.  I asked whether I can delete them without harm.
[16:26] <maxb> Answer: no
[16:27] <feckser> Can I hard link them without harm?
[16:28] <feckser> The duplicate finder (fdupes) smartly considers multiple links to same file as not duplicates.
[18:01] <vila> feckser: don't ever hardlink these files, they contain the signatures (and appear to be empty in your case). If you start signing your commits... they won't be empty anymore
[18:02] <feckser> vila: so as long as I don't sign, they can be hard linked or removed?
[18:03] <vila> feckser: no, their presence is mandatory
[18:03] <feckser> vila: hard linked?
[18:03] <vila> feckser: if you hardlink them, you will be doomed the day someone in the project sign a commit
[18:03] <exarkun> it really sounds like you want fdupes to have an exclusions list :)
[18:04] <vila> feckser: besides, new ones will be created when the repo is repacked
[18:55] <meoblast001> hi
[18:55] <meoblast001> i'm having more issues with obtaining the directory of a branch
[18:56] <meoblast001> this result.branch.base isn't cutting it anymore
[18:56] <meoblast001> because "filtered-154314860:///bzr/~mysticgalaxies/citrine-blender/" is not a file path
[18:56] <meoblast001> at least not to me it isn't
[18:57] <meoblast001> hm, a lot of stuff is undocumented
[18:57] <meoblast001> i can't even find Branch.base in the docs
[21:09] <lifeless> meoblast001: branch.base is in the api docs
[21:09] <lifeless> pydoc bzrlib.branch
[21:09] <lifeless> ...
[21:09] <lifeless> :ivar base: ...
[21:09] <lifeless> meoblast001: that filtered: prefix is the soft chroot I was telling you about
[21:10] <lifeless> meoblast001: and why taking a suffix is needed, or unwrapping the filtering
[21:10] <lifeless> meoblast001: or, taking a config option from the branch (which I think is preferrable anyway)
[21:10] <lifeless> meoblast001: but you'll know what works best for your needs
[21:17] <meoblast001> lifeless: oh, why wasn't it in these docs http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BzrBranch7.html
[21:17] <meoblast001> hm, those seem to be personal docs
[21:17] <meoblast001> nvm
[21:18] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.Branch.html
[21:18] <meoblast001> ah
[21:19] <lifeless> looks like a bug in pydoctor
[21:19] <meoblast001> config option?
[21:19] <lifeless> its showing inherited methods
[21:19] <lifeless> but not inherited variables
[21:19] <lifeless> attributes I mean
[21:19] <lifeless> meoblast001: config option - setting a key in branch.conf that you can look for
[21:21] <meoblast001> lifeless: does Bazaar call plugins with .bzr as the working directory or is there something i need to use to set and get keys in branch.conf?
[21:21] <lifeless> branch.get_config()
[21:21] <meoblast001> hm, undocumented
[21:21] <lifeless> its a decorator
[21:22] <meoblast001> decorator?
[21:22] <lifeless> I think
[21:22] <lifeless> ah no, it is genuinely undoced, I'll fix
[21:23] <meoblast001> lifeless: does that return a bzrlbi.config.Config?
[21:23] <meoblast001> bzrlib*
[21:25] <lifeless> bzrlib.config.BranchConfig
[21:25] <lifeless> which has get_config, set_config etc apis
[21:27] <meoblast001> lifeless: i seem to have a limited array of options
[21:27] <meoblast001> i see no get_config or set_config
[21:27] <meoblast001> i see get_user_option
[21:27] <meoblast001> but not even a set_user_option
[21:28] <lifeless> http://people.canonical.com/~mwh/bzrlibapi/bzrlib.config.BranchConfig.html
[21:28] <lifeless> there is a set_user_option
[21:28] <lifeless> and get_user_option
[21:29] <meoblast001> ah, at top
[21:29] <lifeless> as well as typed methods for email, signature checking, aliases and so on
[21:29] <meoblast001> lifeless: so i want to use those, correct?
[21:29] <lifeless> in your plugin you want to use get_user_option
[21:29] <lifeless> you can just set the value in branch.conf with a text editor
[21:29] <meoblast001> result.branch.get_config().get_user_option ('blahblahblah')
[21:30] <lifeless> yep
[21:30] <meoblast001> since the return value of that get_config() is still sort of ambiguous
[21:30] <meoblast001> ok, thanks
[21:31] <lifeless> generally speaking that will return None if the option isn't set
[21:41] <mgz> ah, a lifeless.
[21:41] <mgz> did you suggest I look at testrepository for my traceback matcher thing?
[21:42] <lifeless> yes
[21:42] <lifeless> testrepository.tests.matchers.MatchesException
[21:42] <lifeless> needs a little more suger
[21:42] <lifeless> sugar
[21:43] <mgz> will grab and look at.
[21:44] <mgz> hm, yeah, that's looking at exc_info
[21:44] <lifeless> possibly it should be built via composed subclass/equality style matches for each element of the tuple
[21:44] <mgz> which isn't a bad thing in general, but in this case we care about how the strings actually get passed through to the final stream
[21:46] <mgz> having something that takes an input of extract_tb style tuples might be okay though
[21:48] <meoblast001> lifeless: ok, thanks... and i should have the config option set manually?
[21:48] <lifeless> yes
[21:50] <TresEquis> lifeless: how goes the househunt?
[21:50] <lifeless> great
[21:51] <TresEquis> cool
[22:57] <maxb> So, if you have a branch, stacked on another branch, and the base branch has been upgraded to 2a but the stacked one is still 1.x .... can you recover?
[22:58] <lifeless> yes
[22:58] <lifeless> upgrade the stacked one
[23:10] <james_w> lifeless: testr is pretty cool, thanks
[23:10] <lifeless> james_w: thanks!
[23:10] <lifeless> I'm glad you like it
[23:11] <james_w> lifeless: I'd prefer different output, like a big green light when all the tests pass
[23:12] <lifeless> james_w: I'd be delighted to incorporate patches
[23:12] <lifeless> if you wanted to include an arduino control module to drive a traffic light, we could even include that
[23:12] <james_w> heh
[23:12] <lifeless> did you see that?
[23:13] <james_w> I saw one that did lava lamps
[23:13] <james_w> I ported soupmatchers to use the discovery stuff today, makes for a pretty nice setup.
[23:13] <lifeless> awesome
[23:13] <lifeless> could you comment on the testtools bug about how that hangs together ?
[23:14] <james_w> I find the output on failure a little unpleasant, but can live with it
[23:14] <lifeless> or in some fashion write it up? That would be _most_ useful
[23:14] <james_w> sure
[23:15] <james_w> lifeless: if you could review the merge proposal that would be great
[23:17] <lifeless> which one ?
[23:17] <lifeless> bah
[23:17] <lifeless> which one ?
[23:19] <james_w> lifeless: https://code.edge.launchpad.net/~james-w/subunit/discovery/+merge/26893
[23:19] <lifeless> thanks!
[23:19] <lifeless> I shall peruse
[23:20] <lifeless> james_w: ah, I see
[23:21] <james_w> lifeless: feel free to suggest alternative implementation strategies, it was more of an exploratory hack, but it works :-)
[23:21] <lifeless> so TestProgram can take the name of a callable
[23:21] <lifeless> or callables
[23:22] <lifeless> one way to do discover would be:
[23:22] <lifeless> make a series of callables, assign them to global names
[23:23] <lifeless> globals()[thunkN] = lambda:loader.discover(arg, pattern=options.discover_pattern)
[23:23] <lifeless> or something like that
[23:23] <lifeless> I don't think what you've done is all that ugly
[23:23] <lifeless> have a play, see what you think
[23:23] <lifeless> if you decide that the current stuff is better
[23:23] <lifeless> then lets ditch TestProgram entirely
[23:24] <lifeless> so that we don't have two different paths.
[23:24] <lifeless> ideally though, lets get a fixed TestProgram class in that file, which we can use appropriately, and submit a patch to python to make the stdlib one sufficient.
[23:25] <james_w> ah, you're saying that TestProgram should be able to take a list of callables, rather than it being a current feature?
[23:31] <lifeless> no
[23:31] <lifeless> it currently takes a list of names
[23:31] <lifeless> and does introspection
[23:32] <lifeless> see the testr.conf for testrepository, for instance
[23:32] <lifeless> (testrepository.tests.test_suite)
[23:32] <lifeless> oh bleh
[23:32] <lifeless> yes
[23:32] <lifeless> I'm saying that if we need to change TestProgram to accept callables as well as names
[23:32] <lifeless> or some such
[23:32] <lifeless> then we should
[23:32] <lifeless> or if we need to separate the concerns more
[23:32] <lifeless> then we should do that
[23:34] <lifeless> james_w: to put it most broadly:
[23:34] <lifeless>  - subunit.run should be a trivial change to testtools.run
[23:35] <lifeless>  - testtools.run should be a trivial wrapper for python's TestProgram
[23:35] <lifeless> so lets make things better up the stack, and where we have to wait for patches to be accepted / propogate to old versions etc, we should have a subclass that implements what our patch does, with a 'XXX: delete when python2.7 is the oldest version we support', or similar.
[23:37] <james_w> right
[23:37] <james_w> I don't see TestProgram taking a list of callables right now
[23:37] <lifeless> agreed
[23:37] <lifeless> it does take a list *of the names of callables*
[23:37] <james_w> right
[23:38] <james_w> but serialising the discovered tests back to that seems wrong
[23:38] <lifeless> so here's the review - please change subunit to use testtools more, it hasn't needed to for run as it was sufficient in the stdlib
[23:38] <lifeless> and do the discovery work in testtools
[23:38] <lifeless> and in testtools; either:
[23:38] <lifeless>  - subclass TestProgram and make it more suitable
[23:39] <lifeless>  - use a thunk to pass to TestProgram
[23:39] <lifeless> james_w: it wouldn't be serialising
[23:39] <lifeless> james_w: it would just call indirect the call to discover; I don't have a preference though
[23:39] <james_w> should we push --discover in to TestProgram?
[23:40] <lifeless> ultimately, yes. In fact 2.7 may do that already
[23:40] <lifeless> so it may be a 'copy from python' case
[23:40] <lifeless> as far as licencing goes
[23:40] <lifeless> testtools is license compatible with python, deliberately.
[23:40] <lifeless> so is subunit.
[23:40] <lifeless> just need to update the list of external copyright holders in the docs.
[23:40] <james_w> it doesn't yet, I was just checking that
[23:41] <james_w> oh, hang on
[23:41] <lifeless> I'm sure 2.7 supports discovery in some fashion
[23:41] <james_w> it does
[23:41] <lifeless> COPYING has the external copyright refs
[23:41] <james_w> but not --discover
[23:41] <james_w> it would be "python -m testtools.run discover"
[23:45] <lifeless> thats ... interesting
[23:50] <lifeless> uhm
[23:51] <lifeless> I don't have a strong opinion here, if it works +1. If its maintainable +1. If its the same as python has ended up upstream thats nice; if you think its nicer to be different, thats ok too.
[23:51] <lifeless> Just, where we are different, put patches forwardds.
[23:51] <lifeless> if you think we should try it differently, and decide later what is nicest, thats fine too - we can put a patch in once we are convinced one way or the other.
[23:52] <lifeless> back shortly, popping down to the bank.