On Thu, Oct 09, 2003 at 10:59:13AM -0500, Manoj Srivastava wrote: > On Thu, 9 Oct 2003 14:15:03 +0200, Bill Allombert > <[EMAIL PROTECTED]> said: > > > My first goal is to persuade developers that running tests is > > worthwhile. For the implentation I have mainly 3 questions: > > > 1) Do porters and autobuilders admins want to be able to skip the > > tests ? > > i) This would, indeed, depend on the tests; if the tests take > 4GB of ram and 48 hours, then thay are probably > inappropriate
I assume you won't mind applying common sense here ? > ii) However, not having the tests run by default would greatly > reduce the benefit of having the tests in the first place I agree. > iii) I haven't heard about any repurcussions on the buildd's from > having to run the tests in gcc, flex etc, so are you sure this > is required? Not being involved in the autobuilder process, I wanted to gather input from porters before reaching any conclusion. At this stage, I don't think it is required, unless maybe by the maintainer. Maybe an optionnal 'notest' DEB_BUILD_OPTIONS can be more than sufficient to handle this case. > > 2) Do we need a more featureful test machinery that just running > > test in the debian/rules build ? > > I think this is the wrong question. Sounds like a solution > begging for a few use cases. We already have packages that do run > time tests; and language infrastructures like Perl already have tests > harnesses; before we go about speculatig about designing yet another > testing harness we should have a good, solid set of use cases that > require such machinery. From comments from you and others on the list, I see that quite a number of tests are already done with the current machinery, more that I was expecting, so probably we don't need another interface. > > 3) Do we want to allow for autorecovery ? If gcc -O2 leads to a > > broken binary, why not set up debian/rules to automatically retry > > with gcc -O0 ? > > I think this is a bad idea. How many successful auto recovery > mechanisms have you seen in the wild? If they are so rare, why are we > debating standard practices and policy based around such vapour ware? Are we ? Well, I have a package (pari) with the bad habit of triggering optimisation error on at least one architecture (it was ARM last time). I will implement that for the sake of the experiment. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. [Please CC me on debian-devel, thanks]