A01:01 PM 6/12/2006 -0700, Guido van Rossum wrote: >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.
I think there's some kind of misunderstanding here. I didn't ask for veto or prior permission. I just want to keep the external release in sync. I also didn't roll anything back, at least not intentionally. I was trying to merge the Python changes into the external release, and vice versa. Two-way syncing is difficult and error-prone, especially when you're thinking you only need to do a one-way sync! So if I managed to roll something back *un*intentionally in the process last night, I would hope someone would let me know. That was my sole complaint: I requested a particular change process to ensure that syncing would be one-way, from wsgiref to Python. If it has to be the other way, from Python to wsgiref, so be it. However, my impression from PEP 360 was that the way I was asking for was the "One Obvious Way" of doing it. This is not now, nor was it ever a control issue; I'd appreciate it if you'd stop implying that control has anything to do with it. At most, it's a widespread ignorance and/or misunderstanding as to the optimum way of handling stdlib packages with external distribution. It sounds like Barry has a potentially workable way of managing it that might reasonably be blessed as the One Obvious Way, and I'm certainly willing to try it. I'd still rather have a Packages/ directory, but beggars can't be choosers. However, if this is to be the One Obvious Way, it should be documented in a PEP as part of the "how packages get in the stdlib and how they're maintained". _______________________________________________ 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
