Enable travis on fork branches with normalized naming scheme

[aktech]

Currently the travis runs on master and branches like 2.7, 3.2, (number.number), which prevents running travis on fork branches which have custom names. This PR introduces a normalized naming scheme for branches: bpo-32368238 (bpo-some_number). So as to enable running travis on fork branches with this naming scheme.

This could help the contributors in testing on their own travis.
For example: https://travis-ci.org/aktech/cpython/builds/203125688

[the-knights-who-say-ni]

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow these steps to rectify the issue:

1. Sign the PSF contributor agreement
2. Wait at least one US business day and then check "Your Details" on bugs.python.org to see if your account has been marked as having signed the CLA (the delay is due to a person having to manually check your signed CLA)
3. Reply here saying you have completed the above steps

Thanks again to your contribution and we look forward to looking at it!

[berkerpeksag]

-1. If people want to test something on their fork before opening a PR, I think they can edit .travis.yml on their fork. Note that if your patch is not ready for code review yet and you want to run the test suite on Travis, it's perfectly fine to open a PR and add "[WIP]" prefix to the PR title.

Also, people can name their branches differently and we can't add every different naming scheme to travis.yml.

[methane]

I agree with @berkerpeksag .

FWI, you can create pull request in your fork to run Travis.
See methane#3 for example.

[aktech]

I and @ncoghlan were discussing about this during PyCon Pune sprints for enabling travis for atleast some naming schemes, without explicity editing .travis.yml in every [WIP] PR.

[ncoghlan]

I like @methane's idea of suggesting that folks create local PRs in their fork in order to trigger Travis without maintaining a WIP PR against the main CPython repo.

@aktech: Would you mind browsing through the developer guide looking for a section where it may make sense to add a new subsection talking about this, and then file a suggestion (or PR!) about recommending that approach? The Developer Guide repo and issue tracker is at https://docs.python.org/devguide/

[aktech]

@ncoghlan The method suggested by @methane sounds good to me as well, Just tried it on my repo. I will soon open a PR, suggesting this technique in developer guide at a suitable place.