Phillip J. Eby wrote: > Actually it's both irrelevant and insulting. > > I just want changes made by the Python core developers to be reflected in > the external releases. I'd be more than happy to move the external release > to the Python SVN server if that would make it happen. >
I think the only way to guarantee that is that you track the Python source code yourself. Here is how I did it with PyXML: - whenever I want a two-way sync, I first look at the changes that happened in Python since the last two-way sync. - of those changes, I eliminate all that where already applied to PyXML. I had the habit of using identical checkin messages, so it was easy to identify which changes already existed in the other tree. - I applied the remaining changes, one by one, to PyXML (but with a single commit), using the same commit messages, and indicating that PyXML was syncronized up to revsion XY with Python. - Then I copied all remaining changes from PyXML to Python, again indicating in the commit messages what the original changes were, and how they got synchronized. Ideally, the PyXML sources and the Python sources should now be identical, byte for byte. Of course, this approach recently broke when byte-for-byte identity was deliberately broken; until then, it worked fine for several years. > The "nail" here is simply that maintaining two versions of a package is > awkward if changes are being made in both places. I'd love to have only > one place in which wsgiref is maintained, but Python's current directory > layout doesn't allow me to put all of wsgiref in "one place". I guess you just have to accept that. It will happen again. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
