On Sat, Mar 28, 2020 at 6:19 PM Bruno Haible <br...@clisp.org> 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
