Re: basing the patches against the latest master branch or targeting released versions, I wasn't clear enough about my thinking.

For sure, when trying to get any patches merged, the submitted patch must be re-based (forward ported) and tested against the master branch. 

But from the perspective of having a project that people can reliably expect to build a working MinGW-w64 Python from (until that elusive fully-merged-day comes), having patches based on the latest released versions seems to me to be the best thing to do (for that goal of course)

I'll keep forward porting these patches to each new release, and at those times I'll also submit some of them as issues to bugs.python.org as that's the best way for me to manage my limited spare time.

Do you know what the situation is with packaging/distutils2? I think our next good merge opportunity for the bulk of these patches will be when we can target that instead of distutils.

> Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build?

I'm already doing that:
https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0

0000 and 0005 are now merged with upstream. 0000 you merged today, 0005 was merged also (mostly via Roumen's patches which 2/3 of my patch duplicated). At this stage, the framework for cross compiling Python is mostly merged; other than 0065-cross-dont-add-multiarch-paths-if-cross-compiling.patch

The stumbling block for me is that there's no working example of cross-compilation in CPython so it will surely rot. This was what I tried to fix with my next patch, 0010-cross-darwin-feature.patch. I went for darwin instead of MinGW as the amount of changes needed is tiny but it was met with some resistance and hasn't seen any activity for 3 months:

http://bugs.python.org/issue16291

I should also clarify, by cross compilation I'm specifically excluding GNU-Linux/GNU-Linux combinations such as x86-GNU-Linux/arm-GNU-Linux as they're not as exhaustive a test-case as cross-compiling between different OSes.

> Maybe you could even separate the patches into a patch supporting a native mingw build and a cmingw ross build?

Not sure if that was directed at me as my set of patches are logically split up I think. Ones with 'mingw' in the name relate to mingw (either cross or native), ones with 'msys' in the name relate to building mingw natively and ones with 'cross' in the name relate to general cross compilation matters; ones with 'hack' in the name generally need improving, rewriting or removing.