Re: [Python-Dev] Please stop changing wsgiref on the trunk
Hi Phillip, On Mon, Jun 12, 2006 at 12:29:48PM -0400, Phillip J. Eby wrote: > This idea would address the needs of external maintainers (having a single > release history) while still allowing Python developers to modify the code > (if the external package is in Python's SVN repository). It's actually possible to import a part of an SVN repository into another while preserving history. That would be a way to move the regular development of such packages completely to the Python SVN, without loss. A bientot, Armin ___ 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
Re: [Python-Dev] Please stop changing wsgiref on the trunk
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: > >IOW I think PEP 360 is an unfortunate historic accident, and we would > >be better off without it. I propose that we don't add to it going > >forward, and that we try to get rid of it as we can. > > 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want > to get rid of it, *now* would be the time. I'm all for it. While I am an enthusiastic supporter of several of those additions, I am *not* in favor of the special status granted to software contributed by certain developers, since it is a burden for all other developers. > There is an approach that would address this issue and others relating to > external packages, but it would require changes to how Python is > built. That is, I would propose a directory to contain > externally-maintained packages, each with their own setup.py. These > packages could be built and installed with Python, but would then also be > separately-distributable. > > Alternately, such packages could be done using svn:externals tied to > specific release versions of the external packages. > > This idea would address the needs of external maintainers (having a single > release history) while still allowing Python developers to modify the code > (if the external package is in Python's SVN repository). Even that is a burden on regular Python developers. For example, when I do "svn up" in the PEPS directory, which has such an arrangement for the docutils, it usually spends (much) more time deciding that there's nothing new in the docutils than it spends on the rest of the update. I also suspect that the external linking will continue to cause a burden for Python developers -- upgrading to a newer version of the external package would require making sure that no changes made by Python developers in the previous release bundle are lost in the new release bundle. I personally think that, going forward, external maintainers should not be granted privileges such as are being granted by PEP 360, and an inclusion of a package in the Python tree should be considered a "fork" for all practical purposes. If an external developer is not okay with such an arrangement, they shouldn't contribute. Note: I'm saying "going forward". I'm not saying that this "tough luck" policy should be applied to the packages that have already been accepted; I don't want the PSF to break its work. Although I'd encourage their authors to loosen up. Perhaps issues like these should motivate us to consider a different source control tool. There's a new crop of tools out that could solve this by having multiple repositories that can be sync'ed with each other. This sounds like an important move towards world peace! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Please stop changing wsgiref on the trunk
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote: >IOW I think PEP 360 is an unfortunate historic accident, and we would >be better off without it. I propose that we don't add to it going >forward, and that we try to get rid of it as we can. 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want to get rid of it, *now* would be the time. There is an approach that would address this issue and others relating to external packages, but it would require changes to how Python is built. That is, I would propose a directory to contain externally-maintained packages, each with their own setup.py. These packages could be built and installed with Python, but would then also be separately-distributable. Alternately, such packages could be done using svn:externals tied to specific release versions of the external packages. This idea would address the needs of external maintainers (having a single release history) while still allowing Python developers to modify the code (if the external package is in Python's SVN repository). ___ 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
Re: [Python-Dev] Please stop changing wsgiref on the trunk
On 6/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > As requested in PEP 360, please inform me of any issues you find so they > can be corrected in the standalone package and merged back to the trunk. > > I just wasted time cutting an 0.1.1 release of the standalone wsgiref > package only to find that it doesn't correspond to any particular point in > the trunk, because people made changes without contacting me or the > Web-SIG. I then spent a bunch more time figuring out how to get the > changes out and merge them back in to the standalone version such that the > Python trunk has a specific version number of wsgiref. Please don't do > this again. > > I appreciate the help finding bugs, but I'll probably still be maintaining > the standalone version of wsgiref for a few years yet. Phillip, Please consider the burden for Python developers who have to remember who owns what code. I know we have PEP 360, but the more I think about it, the more I believe it's unreasonable to have growing amounts of code in the Python source tree that cannot be modified by Python developers who are taking the usual caution (understanding the code, running unit tests, being aware of backwards compatibility requirements, etc.). Once code is checked into Python's source tree, change control should ideally rest with the Python developers collectively, not with one particular "owner". IOW I think PEP 360 is an unfortunate historic accident, and we would be better off without it. I propose that we don't add to it going forward, and that we try to get rid of it as we can. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
[Python-Dev] Please stop changing wsgiref on the trunk
As requested in PEP 360, please inform me of any issues you find so they can be corrected in the standalone package and merged back to the trunk. I just wasted time cutting an 0.1.1 release of the standalone wsgiref package only to find that it doesn't correspond to any particular point in the trunk, because people made changes without contacting me or the Web-SIG. I then spent a bunch more time figuring out how to get the changes out and merge them back in to the standalone version such that the Python trunk has a specific version number of wsgiref. Please don't do this again. I appreciate the help finding bugs, but I'll probably still be maintaining the standalone version of wsgiref for a few years yet. ___ 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
