Luke Kenneth Casson Leighton added the comment: the last time this was brought up on python-dev the opinions of the primary python developers was made very very clear: anything that is not written by them is treated with extreme hostile and predudicial contempt.
what i mean by that is that the view of the primary python developers is that when they make decisions to decrease their workload, other people are *NOT* welcome to question those decisions. [i questioned their decisions; all bugreports were terminated with excuses without good technical justification, and when i questioned those, access to the bugtracker was terminated]. roumen's work should have been encouraged and welcomed when it was first initiated - FIVE years ago. the best bet therefore is to go over the heads of the primary python developers and to approach the Python Software Foundation's Board of Directors. they are required to enact the PSF Charter in the best interests of the Python Programming Language. what the existing primary python developers can or cannot cope with is of secondary consequence for the Board. the main concern of the primary python developers was that they would be landed with yet another platform to support, and, as they are struggling to cope with the existing ones, they made - and make - absolutely any excuse that they can, regardless of actual merit, to ensure that no other platforms are added. roumen, my opinion is that you have demonstrated over the past five years that you are committed to ensuring that python gets mingw support, and that you yourself are the best person to become the maintainer of python-mingw. you are, already, de-facto, its maintainer. answering some other points: * python-mingw actually requires an entire new platform (built in to sys and os at a fundamental level). neither the platform rules for cygwin, nor the platform rules for gcc, *nor* the platform rules for win32 correctly apply. the MSVC platform rules should also be obviously understood to be useless. mingw uses gcc, but it is gcc for win32: it therefore falls through *all* the existing platforms and requires its own separate class in distutils. * the autoconf-generated pyconfig.h is so insanely slow to generate under mingw (any configure script running under MSYS is insanely slow) that it is virtually impossible to do any development. also, the hard-coded config header file for win32 is also useless: firstly mingw doesn't have all the features of win32 (the headers are reverse-engineered and so are incomplete). secondly, the hard-coded config header file for win32 has MSVC-specific details in it that make it useless. * distutils was frozen because several immature developers made improperly tested commits that caused massive disruption. rather than put in proper review procedures, the primary python developers decided to terminate all possibility of ever adding in a new platform - ever - and began distutils2. this situation has to be reversed. mingw *requires* that distutils have support for the mingw compiler. a way to achieve this is to add separate files into distutils (which cannot be questioned as to their effect on existing files in distutils, because they are separate and therefore have zero effect), and then, once those files have been added and accepted, create a *ONE* line patch to distutils which pulls in the new mingw distutils functionality. a one-line patch cannot really be argued with, esp. if it is only an "include". roumen and others: i recommend that you approach the Python Software Foundation and ask that this project be sponsored for 3 months and/or until it is completed and the patches are in. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3871> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
