Re: Initial Travis smoke testing

[Jeffrey Walton]

On Sat, Mar 28, 2020 at 6:19 PM Bruno Haible <address@hidden> wrote:
>
> Hi Jeffrey,
>
> > The initial Travis smoke test went in today. It is on my testing fork
> > at https://github.com/noloader/gnulib.
>
> I appreciate that you are going forward!
>
> > The big TODO is, how to partition the list so every module is tested
> > at least once a week or every two weeks.
> >
> > Does anyone have an idea about partitioning the tests? (I have some,
> > but I don't want to taint suggestions).
>
> An idea could be as follows:
>
>   - Fix a number N of test runs for which you are going to store the
>     list of tested modules.
>   - For a new test run:
>     1. Take the set of all modules, minus the modules that were selected
>        in the last N test runs.
>     2. If this set is empty, print "N is too large", decrement N, and go
>        to step 1.
>     3. Otherwise select up to, say, 5 elements of this module set at random.
>     4. Invoke './gnulib-tool --create-testdir --single-configure ...'
>        with these module names.
>     5. gnulib-tool prints the full list of modules. Store them in the
>        list of tested modules.
>
> This way, modules at the "top" of the dependency hierarchy will not
> be tested frequently, but through step 1, a certain amount of redundancy
> is avoided.
>
> If this doesn't work because you can't store things between runs, I would
> vote for some clever algorithm on the dependency graph.

Yep, that's the problem. No state between runs.

Jeff