Travis runs on all branches

[max-sixty]

Was there a reason to have this filter?

The existing code wouldn't kick off travis runs on my fork's travis (i.e. https://travis-ci.org/max-sixty/ndarray/branches), which I think means I need to create a PR to see a travis run.

The proposed code will kick off a travis run on any branch (on forks which have travis enabled)

But if this was deliberate for some reason then feel free to close

[max-sixty]

Gentle reminder on this, lmk any feedback, thanks

[burrbull]

You can better add trying branch into .travis.yml whitelist. And when you need to test some branch, create copy of it with name trying (like bors-ng do when you call bors try).

[max-sixty]

@burrbull What advantage does that have over the proposed changes?

[burrbull]

This repo has 15 branches and a lot of forks. You want to make travis to build after any change in any branch. It's bad way.

[max-sixty]

TBC, this repo's Travis only runs on a change in a fork if that fork has a open PR - it's the other fork's travis that would run on a change.

I maintain https://github.com/pydata/xarray, which has 408 forks, and the proposed model works great. I've never seen the existing model before - is it prevalent?

[LukeMathWalker]

My understanding is in line with @max-sixty - it will only run on ndarray's Travis when a PR is open. But it will run on the fork CI while you are working on it, before opening a PR.

Unless there is something I am missing, I would go ahead and merge the change after #628 is finalized.

[LukeMathWalker]

No need to wait in the end, the conflict would be extremely minor.

[max-sixty]

Cheers @LukeMathWalker !