=== Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [06:55] what are snapshots used for ? === Ursinha-afk is now known as Ursinha [19:36] how can I run doctests from a specific lib/lp//stories/webservice directory [19:41] bin/test -t application/stories/webservice [19:41] cr3: I hope you're not adding a new application though [19:41] cr3: or that your definition of application is not mine [19:41] lifeless: sure am [19:42] lifeless: maybe a bit from column A and a bit from column B [19:42] lifeless: I'm adding the /+results namespace for the Results Tracker [19:43] I thought that that was going to use a different DB [19:43] as per the discussions you me & jml had it prague [19:43] lifeless: flacoste and jml preferred it to be in the same db [19:44] mmmm [19:44] do you have minutes from that? I was there with jml when we talked about this [19:44] lifeless: yeah, different db was indeed my original intention but that changed following discussion in montreal with both parties mentionned [19:44] and he didn't express such a preference at the time [19:44] lifeless: are you sure that discussion was in prague rather than belgium? [19:45] Could you please drop me, jml, flacoste and thumper (virtual flacoste for a few weeks) a mail about this. Is there a LEP for what you're working on ? [19:45] cr3: after the LP epic, at the platform sprint. Very sure. [19:45] lifeless: https://dev.launchpad.net/LEP/ResultsTracker [19:45] cr3: I don't believe jml has been to montreal since then [19:46] lifeless: right, that's why I'm surprised the idea of a separate db was still around in prague [19:46] because: [19:46] well, actually, let me read the LEP [19:48] ok, I've read it [19:48] uhm. [19:48] When did you last sync up with jml on this ? [19:49] lifeless: last we spoke was on the 15th of june, haven't had an opportunity to start working on the project since [19:50] lifeless: I've quite excitedly started end of last week and perhaps it's been so long that a resync would be in order [19:50] well [19:50] here's my understanding [19:50] you were going to build a separate system, and integrate it into the LP UI [19:50] it was going to be separate because: [19:51] - there's no solid schema for it yet, and changing schemas in LP is *extremely hard* [19:51] - its not part of the core LP mission [today], and jml has a sort-of moratorium on putting more stuff in LP until we're actually really polished on we do do [19:52] I'm personally very excited about what you're working on. [19:52] If I have misunderstood, thats cool. [19:52] I have a -very- important thing for you though, either way. [19:52] *do* land every little thing separately. [19:53] *do not* get it all working and then submit it. LP's review process will not accept such a proposal. [19:53] my initial proposal was design mostly to address the second concern rather than the first one. however, during my discussion with flacoste and jml in montreal (before the epic), it was decided that the results tracker should be in the core Launchpad (to my surprise :) [19:54] lifeless: heh, that's actually why I'm working today. I started having too much code and I wanted to split that a bit into minimal chunks [19:54] and when I say "too much", I really don't mean that much, but more than minimal :) [19:55] cr3: have you seen the review policy LP has on this? [19:55] lifeless: I've been reading much of dev.l.n, but not the review policy. I've heard about the 600 or so line diff thing [19:56] ok cool [19:56] lifeless: I'm very conscious (and afraid) that the review policy is probably very strict and conservative, so I'm developing accordingly... as is launchpad was a little squirrel and I don't want to scare it away :) [19:57] s/as is/as if/ [19:57] many things in LP are not structurally clear [19:57] lifeless: do you still want me to drop you guys an email? [19:57] so its easy to end up reinventing stuff [19:57] cr3: Absolutely [19:58] lifeless: will do [19:58] If its in LP, stub and I will need to get across your entire design to do a schema patch review, and consider all your use cases for indexing, performance, etc etc [19:58] its a freaking huge deal [20:00] lifeless: tracking results is not trivial, so I'm actually glad it's a huge deal as it should be [20:00] * cr3 is taking this freaking seriously [20:00] another reason not to put it in the same big bag [20:01] We have very limited scalability in LP today. [20:01] in 12-18 months I'd expect to be able to handle whatever your workload is; at the moment while we can scale for reads, we can't scale for writes. [20:02] lifeless: in 12-18 months, I think we'll have a solid schema so timing might be right [20:02] lifeless: for now, I'm quite happy making the interface strictly open to members of a specific team. the initial objective is to meet specific user stories one by one [20:03] my current user story is tracking upgrade results from mvo [20:04] cr3: please drop (at least me) a mail, I'll ping jml this evening and flumper during the day [20:04] lifeless: for some reason, bin/test -t results/stories/webservice doesn't run my doctest in the file xx-results.txt. [20:04] don't stop what you're doing [20:05] lifeless: you can't make me! :) [20:05] cr3: you probably haven't setup the doctestsuite [20:17] lifeless: how's that done? [20:17] have a look at one of the other domains [20:18] btw, your result tracker stuff probably belongs in either lp.services.resultstracker or as part of registry. [20:18] sinzui will know more [20:19] lifeless: I'll ask him tomorrow, thanks [20:20] lifeless: I looked at the hardwaredb domain and then tried ./bin/test -t hardwaredb/stories/webservice: 0 tests [20:25] -t is funny about some things, sometime it has to be -t hardwaredb/tests/../stories/webservice [20:30] james_w: that worked for hardwaredb, funny indeed [20:32] * cr3 gots docs tests! [20:33] cr3: also btw [20:33] cr3: in launchpad, doctests are loathed [20:33] cr3: unless they truely are documentation [20:33] cr3: so, ask yourself: would the doctests you are writing be sensible to include on help.launchpad.net [20:33] cr3: if not, they should not be doctests. Please. [20:34] lifeless: yeah, I read something about doctests being loathed in one of the Guides. however, that's where the api seems to be tested which probably makes sense to have on help.launchpad.net too [20:34] cr3: no [20:35] some of the api is tested in doctests, but like nearly every other doctest thats a hangover [20:35] don't copy it [20:35] really don't. [20:35] if you want to write *docs* for something, use doctests. [20:35] lifeless: do you have an example of good unit tests for the api then? [20:35] if you want to write *tests* for something use tests [20:35] cr3: I only know a small fraction of the code base [20:35] perhaps ask on the list [20:36] or look in the code section; they are pretty gung ho testers, I'd expect webservice pyunit tests there [20:36] also remember to be clear what you're testing [20:37] if you're testing that A an B are hooked up in a certain way, test that, rather than testing that calling through A and B to C, D and E works. [20:37] maybe if I have a unit test case use WebServiceLayer, that might work out well [20:38] lifeless: don't worry, I was just testing that the web service worked, I wasn't testing the model layer which actually doesn't exist yet :) [20:38] test_bugs_webservice is one test file I know of that tests webservice stuff via a unit test [20:38] cr3: uhm, that sounds like a valueless test; we know the web service works. [20:39] lifeless: I'm expecting the web service layer to be very thin, most of the code should be in the model layer which should probably use the DatabaseFunctionalLayer (still learning) [20:39] cr3: right, which means you should have approximately zero webservice tests. [20:39] lifeless: we don't know that the '+results' namespace works though [20:40] (note that I also want to talk about that namespace with sinzui tomorrow) [20:40] cr3: but we know the machinery; if you're registered you can do a multiadapter lookup to confirm it works against the relevant model objects, and you're done. [20:40] you might want *a* smoke test [22:03] morning [22:07] morning [22:08] hi thumper, mwhudson [22:08] do either of you know what 'snapshots' are for ? [22:08] yeah [22:08] what are they for ? [22:09] thumper: also, did flacoste mention 'test result tracker' to you at all? [22:09] working out which fields have changed in order to raise the object modified events [22:09] lifeless: no, I didn't get a heads up about the result tracker [22:09] but I have an email from Marc [22:09] ok, I will hunt jml down [22:09] yes, I twisted his arm into mailing :) [22:10] thumper: you probably don't need to do anything regarding it [22:10] good [22:10] :) [22:10] so, is there every any point in having CollectionFields snapshotted ? [22:11] mmm, rather 'which is more comment: CollectionFields should be | should not be snapshotted' [22:11] s/comment/common/ [22:11] it is a bit fluffy [22:12] for example [22:12] ... [22:12] lifeless: intuition says 'should not' would be more common, but i doubt there's a one-size fits all answer [22:12] no, actually I think it should be more common for collections fields to be NOT snapshotted [22:12] mwhudson: Yeah, I'm thinking we should change the default [22:12] thumper: you just agreed with mwhudson [22:12] lifeless: yes I did [22:12] we do that sometimes [22:13] the 'no' confused me ;) [22:13] there's something about the whole objectnotmodified event thing that makes me a bit uneasy somehow [22:13] we don't use it very much [22:14] ! [22:14] and it's a very general mechanism that in full generality is very expensive [22:14] eh? [22:14] lifeless: am i wrong? [22:14] we have a NOT modified event? [22:14] oh sorry [22:14] :-) [22:14] objectmodified event [22:14] mwhudson: I'm just surprised at having an event for objectnotmodified [22:14] dunno where that came from [22:15] mwhudson: some good toenails :) [22:36] lifeless: can you add ian.m.booth to canonical-bazaar team plz? [22:36] lifeless: actually, don't bother [22:39] I'm not sure I can [22:39] but if I can I will if you like [23:27] thumper: looks like jml is awl, so we may need to talk about the test tracker thing brielfy [23:27] lifeless: ok [23:27] please name a time [23:28] how urgent is it to talk about? [23:29] well [23:29] we have a new component, with many unknowns, no in-team maintainer, nor committed-resources-to-handle-oops-etc-from-out-of-team being developed. [23:30] its important to various teams to have it built, and built well, and there is also some confusion over the previously discussed design approaches which occured both before and after I became TA [23:30] so it doesn't have to be today [23:31] but if we do want to change the course, better to do it up front IMO [23:31] * mwhudson glares at staging