At 11:23 AM 6/12/2006 -0700, Guido van Rossum wrote: >developers contributing code without wanting >to give up control are the problem.
Control isn't the issue; it's ensuring that fixes don't get lost or reverted from either the external version or the stdlib version. Control is merely a means to that end. If we can accomplish that via some other means (e.g. an Externals/ subtree), I'm all for it. (Actually, perhaps Packages/ would be a better name, since the point is that they're packages that are maintained for separate distribution for older Python versions. They're really *not* "external" any more, they just get snapshotted for release.) I guess I should say, control isn't the issue for *me*. I can't speak for anyone else. Fredrik has raised the issue of API forks, but I haven't encountered this myself. I *have* seen some developers make spurious "cleanups" to working code that breaks compatibility with older Python versions, though, just not in wsgiref. But I don't mind policing such things myself as long as I have only one subtree to svn log (versus having to track three separate logs and diffs for Lib/wsgiref/, Lib/test/test_wsgiref.py, and Doc/lib/libwsgiref.tex, and then having to reformat the diffs to apply to a different directory layout). Now, Barry's approach to the email package makes good sense to me, and I'd use it, except that SVN externals can't sync individual files. I'd have to create Lib/wsgiref/tests (and make a dummy Lib/test/test_wsgiref that invokes them) and Lib/wsgiref/doc (and make Doc/lib/lib.tex include libwsgiref.tex from there). If those changes are acceptable, I'd be happy to take that as a compromise approach. I'll still have to manually update the Python PKG-INFO (due to no setup.py), but it'd be better than nothing. _______________________________________________ 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
