Re: [Python-Dev] External Package Maintenance
Guido van Rossum wrote:
developers contributing code without wanting to give up control are the problem.
That hits the nail on the head. If something is added to the standard library, it becomes part of Python and must be controlled by whoever controls Python. Otherwise there will be chaos. If a developer puts his code into the standard library, it may or may not increase their status, ego, or income. Each developer must decide for himself. I suggest that the BDFL make a Pronouncement on this subject.
On 6/12/06, Edward C. Jones <edcjones@comcast.net> wrote:
Guido van Rossum wrote:
developers contributing code without wanting to give up control are the problem.
That hits the nail on the head. If something is added to the standard library, it becomes part of Python and must be controlled by whoever controls Python. Otherwise there will be chaos. If a developer puts his code into the standard library, it may or may not increase their status, ego, or income. Each developer must decide for himself.
I suggest that the BDFL make a Pronouncement on this subject.
I think I pretty much did already -- going forward, I'd like to see that contributing something to the stdlib means that from then on maintenance is done using the same policies and guidelines as the rest of the stdlib (which are pretty conservative as far as new features go), and not subject to the original contributor's veto or prior permission. Rolling back changes without discussion is out of the question. (Sometimes it's okay to roll back a change unilaterall, but that's pretty much only if it breaks the unit tests and the original author does not respond to requests to fix his mistake within a reasonable time.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
At 03:42 PM 6/12/2006 -0400, Edward C. Jones wrote:
Guido van Rossum wrote:
developers contributing code without wanting to give up control are the problem.
That hits the nail on the head.
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. If there was only one release point for the package, I would've had no problem with any of the changes made by Tim or AMK or anybody else. The "control" argument is a total red herring. If I had an issue with the actual changes themselves, I'd address it on checkins or dev, as is normal! 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". And if we hit *that* "nail" on the head (instead of hitting the external authors on theirs), it is a win for all the external contributors.
Fredrik Lundh wrote:
I just want changes made by the Python core developers to be reflected in the external releases.
and presumably, the reason for that isn't that you care about your ego, but that you care about your users.
For that, yes. However, the reason to desire that no changes are made to Python's wsgiref is just that he wants to reduce the amount of work he has to do to keep the sources synchronized - which reduces his amount of work, but unfortunately increases the amount of work to be done for the other python-dev committers. Regards, Martin
At 12:56 AM 6/13/2006 +0200, Martin v. Löwis wrote:
Fredrik Lundh wrote:
I just want changes made by the Python core developers to be reflected in the external releases.
and presumably, the reason for that isn't that you care about your ego, but that you care about your users.
For that, yes. However, the reason to desire that no changes are made to Python's wsgiref is just that he wants to reduce the amount of work he has to do to keep the sources synchronized - which reduces his amount of work, but unfortunately increases the amount of work to be done for the other python-dev committers.
I see *now* why that would appear to be the case. However, my previous assumption was that if somebody found a bug, they'd tell me about it and I'd do the work of fixing it, updating the tests, etc. In other words, I was willing to do *all* the work, for changes that made sense to wsgiref. What I didn't really "get" until now is that people might be making Python-wide changes that don't have anything to do with wsgiref per se, and that is the place where the increased work comes in. This should definitely be explained to authors who are donating libraries to the stdlib, because from my perspective it seemed to me that I was graciously volunteering to be responsible for *all* the work related to wsgiref. (And yes, I understand now why it doesn't actually work that way.)
Phillip J. Eby wrote:
This should definitely be explained to authors who are donating libraries to the stdlib, because from my perspective it seemed to me that I was graciously volunteering to be responsible for *all* the work related to wsgiref.
It's not only about python-wide changes. It is also for regular error corrections: whenever I commit a bug fix that somebody contributed, I now have to understand the code, and the bug, and the fix. Under PEP 360, I have to do all of these, *plus* checking PEP 360 to determine whether I will step on somebodies' toes. I also have to consult PEP 291, of course, to find out whether the code has additional compatibility requirements. I currently mostly manage to do this all because I remember (in brain) whether something is externally maintained, and how to proceed in this case. However, I can see how this doesn't scale. So ideally, I would like to see the external maintainers state "we can deal with occasional breakage arising from somebody forgetting the procedures". This would scale, as it would put the responsibility for the code on the shoulders of the maintainer. It appears that Thomas Heller says this would work for him, and it worked for bsddb and PyXML. Regards, Martin
At 01:49 AM 6/13/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
This should definitely be explained to authors who are donating libraries to the stdlib, because from my perspective it seemed to me that I was graciously volunteering to be responsible for *all* the work related to wsgiref.
It's not only about python-wide changes. It is also for regular error corrections: whenever I commit a bug fix that somebody contributed, I now have to understand the code, and the bug, and the fix.
Again, my point was that I was volunteering to do all of those things for wsgiref.
Under PEP 360, I have to do all of these, *plus* checking PEP 360 to determine whether I will step on somebodies' toes. I also have to consult PEP 291, of course, to find out whether the code has additional compatibility requirements.
In the wsgiref case, you mustn't forget PEP 333 either, actually. :)
So ideally, I would like to see the external maintainers state "we can deal with occasional breakage arising from somebody forgetting the procedures". This would scale, as it would put the responsibility for the code on the shoulders of the maintainer. It appears that Thomas Heller says this would work for him, and it worked for bsddb and PyXML.
I've also already said I can use Barry's approach, making the Python SVN repository version the primary home of wsgiref and taking snapshots to make releases from. I didn't realize that cross-directory linkages of that sort were allowed, or I'd have done it that way in the first place. Certainly it would've been a more effective use of my time to do so. :)
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
participants (5)
-
"Martin v. Löwis" -
Edward C. Jones -
Fredrik Lundh -
Guido van Rossum -
Phillip J. Eby