Shouldn't this go to vthe 3.0.2-doc to fix #13274?

No clue. I'm super confused on why we have a documentation branch that moves forwards after the code is released. This is also not a documentation fix.
I guess we can backport this to 3.0.2-doc with meeseekv. I'd rather not create a manual patch, as I believe that merging patches on an already release code base is bad practice.

I still think we should apply something like #12398 and not run full tests for doc branches.

This PR still needs to get merged. It fixes something that is unrelated to our docs.

I... don't think the interpretation of the problem is correct?

Right now (since #12878) the 3.0.2-doc branch has the following travis_all.txt:

<elided>
# pytest-timeout master depends on pytest>=3.6. Testing with pytest 3.4 is
# still supported; this is tested by the first travis python 3.5 build
# pytest>=3.8 throws RemovedInPytest4Warning (github #12825)
pytest>=3.6,<3.8
pytest-cov
pytest-faulthandler
pytest-rerunfailures
pytest-timeout
pytest-xdist
<elided>

and the following travis35.txt (constraints file):

<elided>
pytest==3.4
pytest-cov==2.3.1
pytest-timeout==1.2.1  # Newer pytest-timeouts don't support pytest 3.4.
pytest-rerunfailures<5  # newer versions require pytest3.6
<elided>

so we're giving pip contradictory constraints on pytest. I guess it would be nicer if pip signalled this properly, but I think(?) the correct fix on our side is to make the constraints not contradictory anymore.

@anntzer The new version is fine, as it installs all the dependencies in the first file, and then installs the pinned version from the second file. Sure, it installs and then downgrades pytests, but it works, and the logic is not flawed.

Would unpinning the version in travis_all.txt work? No, because the new version of pip doesn't care about the order of the requirement files nor whether one version contains a pinned version or the other doesn't. In particular, in our last failed build on 3.0.x, pytest-xdist fails to be installed because it is attempting to install the newer unpinned version from travis_all.txt instead of the pinned version of travis35.txt

Is it the best way to do this? No, it is not, as it installs some of the packages twice. But we have too many dependencies to be able to have a clean setup that doesn't require maintaining entirely separate requirements files for all of the versions we are testing.

Would #12398 not fix the problem much more simply by just not running the test suite on the doc branch?

This patch is not on the documentation branch.

I am extremely confused now. Isn't the 3.0.x branch just fine? The last 5 builds are green on https://travis-ci.org/matplotlib/matplotlib/branches.

@anntzer I'll double check that it works on the doc branch once I'm back from Australia.