Prepare v2.6.1

I'll probably update the history and such in this branch too.

/cc @aanand


LGTM, but it updates urllib3, so we need to co-ordinate with @shazow to make sure he's comfortable with pushing a new release of urllib3 as well.

Thoughts @shazow?


Courtesy nod to @shazow that we'd like to release soon so you might get bugged by downstream redistributors


Also, a head's up to @eriol and @ralphbean that we're planning a release in the event they would like to prepare for that.


I _just_ published the latest master as 1.10.3. Is this something different?


So I pulled in https://github.com/shazow/urllib3/commit/10b7a0fefa6596f47a9a6afc80f1f4d1ae950b66 and https://github.com/shazow/urllib3/commit/0b744993bbe30fe6e3e4e0c93416412d8e598301 is the commit tagged for 1.10.3 which is _not_ in master but on a branch called "release". If those two are merged, I'll make another pull and everything should be fine since the only differing change is 10b7a0fefa which is a modification to the Makefile which we do not include.


Yup, release is a different branch than master, their hashes will never converge (as master has dev-specific stuff, like `__version__ = 'dev'` and release does not). See https://github.com/shazow/urllib3/blob/master/release.sh for details.


Ah okay. I think we need to update our release process then to pull from the release branch unless we specifically need to pull from master. @Lukasa I think you have write access to my fork, would you mind updating our vendored copy of requests to use urllib3 from the "release" branch? If not, I'll do it over lunch or after work today.


Keep in mind that the release branch is only updated when a release happens. If you want to pull things ahead of a urllib3 release, you'll need to get it from master as usual.


:cake: 


:eggplant: 


Sadly, I'm not a collab on your repo @sigmavirus24. =( I opened a pull request instead: sigmavirus24/requests#3.


This is really an overcomplicated thing to do, but ah well.


@ralphbean @eriol after a discussion today, we've decided that the VendorAlias work we had in requests was causing too many problems. If you'd like to include it as a patch for Fedora/Debian we're :+1: on that, but we won't be shipping it. If you find problems with it in the future, I'll be happy to hack on it with y'all to make sure it's robust, thread-safe, etc. and will continue to work for you and for our (people using requests on Fedora/Debian) users.


I also want to find a sustainable long-term solution to this problem. I want to grab some of @dstufft's time (or anyone who really understands python's import machinery) to work out how we can do this long term.


Alright @sigmavirus24, this all LGTM except that the changelog probably needs an update to say that we aren't fixing the machinery, we're just removing it wholesale.


> Alright @sigmavirus24, this all LGTM except that the changelog probably needs an update to say that we aren't fixing the machinery, we're just removing it wholesale.

:heavy_check_mark: 


Make it happen, @sigmavirus24. :shipit: 


Many thanks for the update, I will include it as a patch, and I will be very happy to help on making it robust, thread-safe... I will also put a note on README.Debian explaining why in Debian VendorAlias patch is used, but I don't know how many users look at /usr/share/doc: I will try to monitor all issues here but please ping me on a issue related to Debian. @sigmavirus24 many thanks for your offer, it's highly appreciated! :smile:

I will update requests for Debian during the weekend. Hopefully Debian Jessie will be released on saturday, so I will be able to backport 2.6.1 for Jessie as soon as it will migrate to Debian Testing.


I'll tag v2.6.1 and push it to PyPI.


And 2.6.1 is released


Thanks very much folks :heart: :cake: 


At the end, I decided to not cherry pick this for Debian since Debian and Ubuntu users will suffer due the problems emerged.