[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: testing packages at build



On Thu, Oct 09, 2003 at 10:59:13AM -0500, Manoj Srivastava wrote:
> On Thu, 9 Oct 2003 14:15:03 +0200, Bill Allombert
> <allomber@math.u-bordeaux.fr> 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. <ballombe@debian.org>

Imagine a large red swirl here. 

[Please CC me on debian-devel, thanks]



Reply to: