I believe it's running, but it's a bit backlogged. See
https://travis-ci.org/sympy/sympy/pull_requests.
It appears that each build takes about an hour to three hours to finish after the previous one.
Unfortunately, since I merged
https://github.com/sympy/sympy/pull/10084 (about a week ago), the Travis builds for SymPy are going to be a little slower than they were (which was already slow), because there are now more builds in the matrix. As soon as I create the release branch (I'm basically just blocking on this one issue
https://github.com/sympy/sympy/issues/10082), I will create a new pull request against master which removes support for Python 2.6 and 3.2 (
https://github.com/sympy/sympy/issues/10463), which should speed up the test times a bit (it will remove 10 builds from the matrix). If necessary we can also stop running the allow_failure builds (builds which currently fail due to bugs in Travis or other issues outside of SymPy).
Two other suggestions of things to help:
- Cancel builds for which there are already newer commits on the same branch.
- If you are just waiting on builds because you want to see what tests failed (rather than waiting so that a PR can be merged), you can enable Travis on your fork of SymPy. Travis will then run the tests on your branches independently in their own queue, and you'll be able to see if they pass or not much quicker (but you have to check them yourself; the links on the PRs will still just reference the sympy/sympy Travis builds). Of course, you can also run the tests locally (./bin/test and ./bin/doctest).
Aaron Meurer