Hi all, ... > > @Mimi: As I wrote, I'd suggest moving to docker based travis. I can do it once > > other issues are addressed, if this setup work for your internal travis support > > as well. See examples .travis.yml [1] [2], builds: [3] [4]. > > Advantages are more realistic builds for distro maintainers (different libc and > > libraries versions, you can test old and new distro releases, etc), but maybe > > that's not what you want/need. > > Disadvantage is that sometimes docker releases have temporary packaging related > > issues (first build in [3]; failure in first build [4] is a bug in LTP, corner > > case, which would be otherwise undiscovered a long time). > Nice! I definitely want to move to a docker based travis. How should > we move forward? Should there be a 1.3.1 release now with just the > few changes in the next branch and include the existing travis branch > with changes to address Vitaly's comments? Yes, that would work for me. Travis changes aren't related to the release (it just needs to be published in git), let's give users the fixes. Docker based setup shouldn't take long It's all about to find the dependencies for used distros (I usually keep them in travis/ directory [5] [6]) and agree on the variants (which distros, how many jobs are still meaningful, which crypto and TPM libraries, whether use also: clang, non-intel archs and cross-compilation). Kind regards, Petr > Mimi > > [1] https://github.com/linux-test-project/ltp/blob/master/.travis.yml > > [2] https://github.com/iputils/iputils/blob/master/.travis.yml > > [3] https://travis-ci.org/github/iputils/iputils/builds/714445071 > > [4] https://travis-ci.org/github/linux-test-project/ltp/builds/714400199 [5] https://github.com/linux-test-project/ltp/blob/master/travis/ [6] https://github.com/iputils/iputils/blob/master/travis/
