| kiko-afk | is SteveA still around? | 12:04 |
|---|---|---|
| dilys | Merge to rocketfuel@canonical.com/launchpad--devel--0: ShipItNG: Allow people to place new orders and shipit admins to search for existing requests and approve, cancel or change them. It's also possible to create new standard shipit requests, which are the options presented to users when they place new orders. r=kiko (patch-2342: guilherme.salgado@canonical.com) | 12:25 |
| === rbelem-afk is now known as rbelem | ||
| kiko | YES! | 12:26 |
| lifeless | SteveA: fixed | 12:27 |
| === camilotelles [n=Camilo@20132139198.user.veloxzone.com.br] has joined #launchpad | ||
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has joined #launchpad | ||
| === bradb [n=bradb@modemcable033.209-70-69.mc.videotron.ca] has left #launchpad [] | ||
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| stub | lifeless: Can you please mirror rocketfuel@canonical.com/launchpad--production--1.31 | 03:42 |
| lifeless | done | 03:43 |
| lifeless | stub: how is the z3 test foo coming along - did my suggested design make sense to jim ? | 03:46 |
| stub | I havn't looked at it recently. There is some low hanging fruit I want to make to it first. I think the redesign can be retrofitted after (and it is all tested so we can ensure all the features remain as expected) given time and inclination. I havn't discussed the redesin with Jim though, as I was more interested in ensuring it supports the features we need rather than how it is implemented. | 03:49 |
| lifeless | stub: ok. | 03:50 |
| lifeless | trial has a similar requirement, also implemented 'differently'. I'm thinking I might do up a sibling project to subunit to do unit resource management | 03:51 |
| stub | There is a desire to get something into Python 2.5 I believe | 03:51 |
| lifeless | have I shown you subunit ? | 03:52 |
| stub | Nope | 03:56 |
| lifeless | http://www.robertcollins.net/unittest/subunit | 03:57 |
| lifeless | stub: what do you think ? | 04:12 |
| stub | Could be useful. The new Z3 test runner has the interesting property that the process is only restarted if a teardown reports that something can't be torn down, whereas the subunit model seems to require you to cluster tests that should be run in a seperate process together. | 04:16 |
| lifeless | well, it lets you mix and match | 04:17 |
| lifeless | IsolatedTestCase runs a single test in a separate process on os.fork() supporting systems | 04:17 |
| lifeless | I plan to write an IsolatedTestSuite that runs its contents in a separate process | 04:17 |
| lifeless | thats probably ~1 hr to do. | 04:17 |
| lifeless | (given testing and all) | 04:17 |
| stub | To meet the Z3 requirements it would need to reinvoke the subprocess if a testcase raised a NotImplementedError in its tearDown method. | 04:19 |
| stub | erm... but in english | 04:20 |
| stub | (Which could be done just by building another IsolatedTestSuite on the fly containing the remaining tests and invoking it) | 04:21 |
| === Alinux [n=Ubuntu@p54A3BA43.dip0.t-ipconnect.de] has joined #launchpad | ||
| lifeless | stub: ;0 | 04:24 |
| lifeless | stub: though, I think that that is somewhat ugly and problematic. What if the thing that won't tear down is postgresql. | 04:24 |
| lifeless | stub: I think the Right Thing to do is to stop at that point, and fail. IOW I don't think the requirement is a good or useful one, though maybe I can be convinced. | 04:25 |
| stub | It is used to say 'this test used a fixture that cannot be torn easily/efficiently without restarting the process'. Not 'I failed to tear something down'. | 04:26 |
| spiv | Oh, cute abuse of NotImplementedError :) | 04:27 |
| stub | So a test can say 'I'm going to totally fuck up the global environment, and I can rely on the test runner to clean it up for me'. Without having to move that test to a seperate suite to run in a seperate process. | 04:27 |
| stub | Also, it a test raises NotImplementedError in the setUp, that test should be skipped (eg. for tests that can only run on certain platforms or require dependancies that are not installed). | 04:28 |
| lifeless | stub: I would just make that test derive from IsolatedTestCase which will do that much more easily | 04:28 |
| spiv | (Hmm, I don't think I've ever seen any form of use of NotImplementedError that wasn't at least a mild abuse... ;) | 04:28 |
| lifeless | stub: NotImplementedError in the setUp will result in the test failing in stock pyunit. I'm absolutely positive that that is the wrong way to do 'skipped' tests. But that is a different discussion. | 04:29 |
| stub | lifeless: But that involves messing with the test. If a test uses the FooLayer (or FooResource i would prefer), the FooLayer might change its behavior and start raising NotImplementedError in the Layers teardown. | 04:29 |
| lifeless | stub: this feels very very dirty to me - its abdicating the responsibility to write good testable software by making the testing environment about 3 OOM more complex. | 04:30 |
| stub | It is lowering the barrier to write and maintain tests, and isn't anywhere near an order of magniture more complex, let alone 3. | 04:30 |
| === spiv decoded OOM as "orders of magic" at first | ||
| stub | orders of manure might be approprate for software development ;) | 04:31 |
| lifeless | uhm, its at least 10 times the complexity - it completely breaks ability to construct a test suite and run it in an adhoc maner. | 04:31 |
| lifeless | it mixes all three concepts into one messy pond that someone is going to have to maintain. | 04:32 |
| stub | Why? Your test suite is already forking itself. | 04:32 |
| stub | This already exists in the Z3 test stuff (except the NotImplementedError in setup, which is trivial to add and Jim agreed with) | 04:33 |
| lifeless | forking is quite different from having a TestCase able to find out about the remaining tests. | 04:33 |
| stub | The testcase doesn't need to know about remaining tests | 04:34 |
| lifeless | I know it exists theere, and having seen what z3 does, thats -why- I think it is worth a throw away and redo. | 04:34 |
| lifeless | sigh. As an example, the new z3 runner is not compatible with subunit's planned IsolatedTestSuite, because it breaks the abstraction barrier. | 04:35 |
| lifeless | look, lets not argue about the current implementation, lets talk about the high level goals, and about whether there is a good clean way to achieve them. | 04:35 |
| stub | Yes - if IsolatedTestSuite impllemented the behavior I dscsribe, Z3 would no longer need to do that | 04:36 |
| stub | Or you could refactor Z3 to push the forking behavior into the testsuite (reimplementing IsolatedTestSuite effectively). | 04:36 |
| stub | Although the barrier might still need to be broken for stuff like profiling and code coverage reports - I know little about that. | 04:37 |
| stub | Goals: A test uses one or more fixtures. Ideally the developer doesn't need to add boilerplate to setUp/tearDown to maintain the fixtures. The test runner can do it in many cases. | 04:39 |
| stub | Goals 2: All the tests for a project can be run and a profile report generated to identify the slow tests that might need to be optimized or flagged 'run occasionally' rather than 'run always' | 04:39 |
| stub | Goals 2: All the tests for a project can be run and a code coverage report generated to help identify untested paths. | 04:40 |
| stub | erm...3 | 04:40 |
| stub | Goals 4: It a fixture/resource/layer/whatever we call it of a test decides that it can't be arsed tearing itself down properly, it can inform the runner/suite/whatever and the next test will be run in a fresh process | 04:41 |
| lifeless | stub: so, I don't have time to really do a good job of this right now, being about to fly out. | 04:41 |
| stub | Goals 5: Resources should only be setup/torndown as infrequently as possible. So the suite/runner should sort the order minimizing the invokations. | 04:42 |
| stub | ok. | 04:42 |
| lifeless | stub: can you mail me the goals, and I'll see what I can do wearing my consultant hat about offering a unittest compatible approach to doing them, I'll also give a high level 'invariants to preserve' about unittest, which give it the awesome flexability that we see in things like smalltalk and java, and the python community seems to have forgotten., | 04:42 |
| lifeless | a note on goals - goals 5 has a useful first sentence, but the second one suggests not understanding the object interactions for unittest, which leads to difficulty. ;0 | 04:43 |
| stub | Then perhaps the existing object interactions for unittest are flawed. My understanding is that the suite is resposible for calling the setup-test-teardown sequence though. | 04:45 |
| lifeless | its not. | 04:46 |
| lifeless | the unittest Test interface has one method : 'run(result=None)' | 04:47 |
| spiv | It's remarkably hard to find a good documentation summarising the xUnit design. | 04:47 |
| lifeless | I agree. | 04:47 |
| spiv | (although asking lifeless seems to be a good substitute...) | 04:48 |
| lifeless | it took me, oh about 2 years from first meeting it before it all sunk in and I realised I grokked it. | 04:48 |
| lifeless | at that point, I started proslytising :0 | 04:48 |
| stub | Anyway - the resource cannot tear itself down unless something tells it how many tests are going to be using it. And the test can't tear resources down unless they know about all subsequent tests. So the testsuite or testrunner needs to make it happen. | 04:48 |
| lifeless | stub: I described how to do resources compatibly before, I think, like subunit, that I need to just write proof of concept code. | 04:49 |
| lifeless | and demonstrate tests that run independently AND optimise in the presence of a smarter Suite. | 04:49 |
| lifeless | so - drop me that email :) | 04:49 |
| stub | Tests are never run 'independently' - they always need a runner to invoke them. | 04:50 |
| lifeless | sorry, thats bullshit | 04:50 |
| stub | You run your tests without a TextTestRunner or something? | 04:50 |
| lifeless | absolutely. | 04:51 |
| stub | How? | 04:51 |
| lifeless | robertc@lifelesslap:~/source/unittest/subunit$ PYTHONPATH=lib python | 04:52 |
| lifeless | Python 2.4.1 (#2, Mar 30 2005, 21:51:10) | 04:52 |
| lifeless | [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 | 04:52 |
| lifeless | Type "help", "copyright", "credits" or "license" for more information. | 04:52 |
| lifeless | >>> import subunit | 04:52 |
| lifeless | >>> suite=subunit.test_suite() | 04:52 |
| lifeless | >>> import unittest | 04:52 |
| lifeless | >>> result = unittest.TestResult() | 04:52 |
| lifeless | >>> suite.run(result) | 04:52 |
| lifeless | >>> | 04:52 |
| bob2 | *cough*thatcouldbeadoctest*cough* | 04:52 |
| stub | Ok - so you just implemented your own runner. | 04:52 |
| lifeless | nope | 04:52 |
| lifeless | well, you could argue that I guess. | 04:52 |
| lifeless | but the point is that there is a defined no-dependency from tests executing to a runner | 04:53 |
| stub | If you said that you required a suite, your manual test runner would be almost as simple and more functionality could be available. | 04:54 |
| stub | Agh.... you *have* a suite | 04:54 |
| lifeless | but you cannot mandate a suite either: | 04:54 |
| lifeless | PYTHONPATH=lib python | 04:55 |
| lifeless | Python 2.4.1 (#2, Mar 30 2005, 21:51:10) | 04:55 |
| lifeless | [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 | 04:55 |
| lifeless | Type "help", "copyright", "credits" or "license" for more information. | 04:55 |
| lifeless | >>> import subunit.tests.test_test_protocol | 04:55 |
| lifeless | >>> test = subunit.tests.test_test_protocol.TestTestImports("test_imports") | 04:55 |
| lifeless | >>> test.run() | 04:55 |
| lifeless | thats the defined interface for a TestCase. If that doesn't work, you are no longer pyunit compatible. | 04:56 |
| stub | And that is a problem? | 04:56 |
| lifeless | and so far I've seen no reason to break that interface. | 04:56 |
| lifeless | yes, its a problem. | 04:56 |
| === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| lifeless | unless you want to partition zope related code off from the test of python, you should be compatible with stock python testing tools | 04:57 |
| lifeless | being compatible lets you do nice things such as use stock gui runners, remote test reports and the like | 04:58 |
| stub | Unless the changed API is a good thing and it becomes the new pyunit | 04:58 |
| lifeless | and noone writes them at the moment because *everyone breaks the api* and thus the projects big enough to write such things cannot write them for everyone. | 04:58 |
| lifeless | I'm deathly afraid of a bad changed api becoming the new pyunit. and what I've seen so far is seriously bad IMO. | 04:59 |
| lifeless | its less flexible, more tightly coupled. That makes it harder to extend compatibly and will then be locked in untill python 3000. | 05:00 |
| lifeless | which I really dont want. | 05:00 |
| lifeless | anyway, I'm getting shorter and shorter here, having just had two projects saying the same thing to me at once. | 05:00 |
| lifeless | and I fly in 9 hours | 05:00 |
| lifeless | so.. please email me as soon as possible, I might work on a prototype on the flight | 05:00 |
| spiv | Working code would be very valuable here. | 05:01 |
| lifeless | I certainly get that impression | 05:02 |
| lifeless | sitting down with radix and mumak at the twisted sprint convinced them they can do what they want in a tasteful manner without being gratuitisouly incompatible with pyunit. And they wouldn't be able to use the z3 test runner as easily | 05:03 |
| stub | Anyway - I think the Z3 test runner could be happily mutated into what we want. Really all that is involved is shuffling some code around a bit. And I'm sure Jim would be happy with any changes that help get it acceped into Python 2.5 provided he doesn't lose desirable functionality. | 05:05 |
| stub | About the only bit I think could cause difficulty is the profiling and codecoverage which I mentioned before. | 05:06 |
| lifeless | stub: if thats the case, cool. The _big_ problem at the moment is the manual iteration of the test case composite structure. | 05:06 |
| lifeless | so - email me and jim if you like. | 05:06 |
| lifeless | if you do it today, I'll have the email with me on the plane | 05:06 |
| stub | Yup. Stuff that into an intelligent test suite, and require the layers to implement from a common base class for the setup/teardown only-if-needed stuff to work. | 05:07 |
| lifeless | the thing to note is that test suites are recursive | 05:08 |
| lifeless | so some care is needed ;0 | 05:08 |
| stub | Viral intelligent test suites - it notices that something it is going to recurse to is dumb and wraps it ;) | 05:10 |
| lifeless | mmm | 05:11 |
| lifeless | it notices its recursing to something foreign and it forks() | 05:11 |
| lifeless | that would be ok. | 05:11 |
| dilys | Merge to rocketfuel@canonical.com/dists--devel--0: [trivial] production 1.31 config (patch-111: stuart.bishop@canonical.com) | 05:25 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--production--1.31: Cherrypick patch-2341 (patch-1: brad.bollenbach@canonical.com, rocketfuel@canonical.com) | 05:52 |
| dilys | Merge to rocketfuel@canonical.com/launchpad--production--1.31: Cherrypick patch-2342 (patch-2: guilherme.salgado@canonical.com, rocketfuel@canonical.com) | 06:18 |
| === rbelem is now known as rbelem-zzz | ||
| === Alinux [n=Ubuntu@p54A3AD7C.dip0.t-ipconnect.de] has joined #launchpad | ||
| === robertbb [n=robertbb@d154-20-136-58.bchsia.telus.net] has joined #launchpad | ||
| === Alinux [n=Ubuntu@p54A3AD7C.dip0.t-ipconnect.de] has joined #launchpad | ||
| === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad | ||
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| === dand [n=dand@freenet.cs.utt.ro] has joined #launchpad | ||
| dilys | Merge to thelove@canonical.com/dists--bazaar--1.5: new build (patch-79) | 10:23 |
| === dand [n=dand@freenet.cs.utt.ro] has left #launchpad ["Leaving"] | ||
| === hannosch [i=hannosch@85.182.69.225] has joined #launchpad | ||
| hannosch | jordi: ping? | 12:22 |
| sivang | hey hannosch | 12:25 |
| hannosch | hi | 12:25 |
| hannosch | I am looking for jordi as he wanted to discuss something about how to setup plone in rosetta | 12:26 |
| sivang | hannosch: seems he away, email him so he would get back to you. | 12:43 |
| hannosch | He was looking for me on #plone in response to my last email, so I suppose he wants to discuss something directly ;) | 12:46 |
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #launchpad | ||
| === Nafallo [n=nafallo@unaffiliated/nafallo] has joined #launchpad | ||
| === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| === jinty [n=jinty@210.Red-83-39-7.pooles.rima-tde.net] has joined #launchpad | ||
| === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad | ||
| === rbelem-zzz is now known as rbelem | ||
| === jinty [n=jinty@228.Red-81-36-163.pooles.rima-tde.net] has joined #launchpad | ||
| === rbelem [n=rodrigo@200.231.108.90] has joined #launchpad | ||
| === ubuntulog [n=warthylo@port49.ds1-van.adsl.cybercity.dk] has joined #launchpad | ||
| === Topic for #launchpad: Discussion with Launchpad users and developers. || https://launchpad.net/ || Includes Rosetta and Malone. || Developers' meeting, Thursday 8 Sep, 12:00 UTC | ||
| === Topic (#launchpad): set by SteveA at Thu Sep 1 14:05:24 2005 | ||
| === WaterSevenUb [i=user@195-23-220-91.net.novis.pt] has left #launchpad [] | ||
| salgado | SteveA, around? | 05:29 |
| === WaterSevenUb [n=WaterSev@195-23-220-151.net.novis.pt] has joined #launchpad | ||
| === stub [n=stub@203-217-37-199.dyn.iinet.net.au] has joined #launchpad | ||
| === jinty [n=jinty@221.Red-81-36-165.pooles.rima-tde.net] has joined #launchpad | ||
| === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| === SnakeBite [n=SnakeBit@84.242.143.64] has joined #launchpad | ||
| === robitaille [n=daniel@d154-5-117-228.bchsia.telus.net] has joined #launchpad | ||
| === rbelem-afk is now known as rbelem | ||
| === Alinux [n=Ubuntu@p54A3AD7C.dip0.t-ipconnect.de] has joined #launchpad | ||
| === rbelem is now known as rbelem-afk | ||
| === Seveas [n=seveas@seveas.demon.nl] has joined #launchpad | ||
| === zyga [n=zyga@2-mi2-1.acn.waw.pl] has joined #launchpad | ||
| === robertbb [n=robertbb@d154-20-136-58.bchsia.telus.net] has joined #launchpad | ||
| sd-tux | hi, i want to download a .po file from rosetta but i can't do it because of this BUG : https://launchpad.net/malone/bugs/1978 doe's anybody know how other way to downsload my translations :) ? | 11:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!