On Thu, Feb 7, 2013 at 6:45 AM, Éric Araujo
Bug fixes are possible; changes to keep working with Python (i.e. pyc files are generated in pycache directories after 3.2); changes to be able to build on current OSes (e.g. following Mac dev tools location change, introduction of Debian multiarch, etc.).
Some bugs have been here for so long that everybody depends on them or work around them, or they would be extremely painful to fix (e.g. in the option parsing code) for little benefit, so they are wontfix.
Cleanups, refactorings and improvements were banned by the feature freeze.
I think the points to be clarified are that *new* internal APIs (including new commands, like bdist_wheel) are legitimate in a feature release, and internal changes which don't affect APIs (like some of the tweaks Dave Malcolm and I made to try to make building Python 3 RPMs on RHEL 6 with bdist_rpm less broken) are legitimate in maintenance releases. distutils is going to be around for a long time for backwards compatibility reasons, so if people want to improve it within those constraints they should be allowed to - we just need to be extra careful with maintenance releases, by treating even nominally internal APIs as if they were public. The current interpretation of the situation as a complete "no few features" freeze is overkill, when the setuptools/distribute developers will have plenty of time to send up warning flares during the alpha/beta/rc cycle. An appropriate rule would be more like "no major refactorings of distutils internals" (which may indeed mean distutils never supports metadata versions past 1.1). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia