I think the test failures are now unrelated.

👍 I would merge this now, but I do not have time to backport it so will hold off on that.

I'm happy to backport - you mean to thev2.x branch?

Yes to the 2.x branch. We are basically ready to cut 1.5.2 if we don't hear about any new issues so I think this is too high risk at the moment on 1.5.x and there will probably not be any 1.5 release after 1.5.2

devil's advocate here:

the original reason for vendoring six was because of changes that were
happening in subsequent releases of six that broke our code. I didn't think
it was ever about pypi's reliability.

On Wed, Jun 8, 2016 at 4:28 AM, Jens Hedegaard Nielsen <
notifications@github.com> wrote:

Yes to the 2.x branch. We are basically ready to cut 1.5.2 if we don't
hear about any new issues so I think this is too high risk at the moment on
1.5.x and there will probably not be any 1.5 release after 1.5.2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6545 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-O99YQpZ0juGbDWkFkDiymNZlypTks5qJn0vgaJpZM4IvN2V
.

@WeatherGod I mostly recall the issue being bug reports where by people were getting mpl install without a working version ofsix

I think I was the original advocate for vendoring six. One of the arguments was to protect against new bugs in six, but it was always a fairly weak argument, because six is so widely used and stable now. I suppose another year of six gives some more evidence against that case, and conversely,#6537 is someone hitting a bug that has been fixed in six. So, I'm not saying it's completely cut and dried, but on balance I think unvendoring is better.

closing in favor of#6556

This will land in master via one of the merge cascades.