[Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)

[Phillip J. Eby]

At 10:42 AM 6/12/2006 -0700, Guido van Rossum wrote:
>Sure, but this doesn't require the draconian "I-and-I-only own the
>code" approach that you have.

If there were only one version and directory tree to maintain to do both 
the Python trunk and the external version, I wouldn't mind other people 
making changes.   It's the synchronization that's a PITA, especially 
because of the directory layout.

If we had Externals/ I would just issue snapshots from there.


>And is that such a big deal? Now that wsgiref is being distributed
>with Python 2.5, it shouldn't evlove at a much faster pace than Python
>2.5, otherwise it would defeat the purpose of having it in 2.5. (And
>isn't it just a reference implementation? Why would it evolve at all?)

This is backwards: I'm not the one who evolved it, other Python devs 
did!  :)  I want Python 2.5 to distribute some version of wsgiref that is 
precisely the same as *some* public wsgiref release, so that PEP 360 will 
have accurate info and so that people who want a particular wsigref release 
can specify a sane version number, to avoid the kind of skew we used to 
have with micro-releases (e.g. 2.2.2).


>>If I understand correctly, the main thing it would require is that Python's
>>setup.py invoke all the Externals/*/setup.py files.
>
>I guess that's one way of doing it. But perhaps Python's setup.py
>should not bother at all, and this is up to the users.

However, if Python's setup.py did this, then external developers would get 
the benefit (and discipline) of the buildbots and testing.  That seems like 
a good thing to me.