[Python-Dev] folding cElementTree behind ElementTree in 3.3 (original) (raw)

Eli Bendersky eliben at gmail.com
Fri Feb 10 10:57:48 CET 2012


On Fri, Feb 10, 2012 at 11:43, "Martin v. Löwis" <martin at v.loewis.de> wrote:

IMHO it's no longer a question of "wanting" to take ownership. According to Florent, this has already happened to some extent. "Ownership to some extent" is not a useful concept. Either you have ownership, or you don't.

I don't mind sending Fredrik an email as you detailed. Any suggested things to include in it? I'd ask Fredrik if he wants to yield ownership, to some (specific) other person. What really worries me is the question who that other person is. There is a difference between fixing some issues, and actively taking over ownership, with all its consequences (long-term commitment, willingness to defend difficult decisions even if you are constantly being insulted for that decision, and so on). Not having an owner just means that it will be as unmaintained in the future as it appears to be now.

How does this differ from any other module in stdlib that may not have a single designated owner, but which at the same time is being maintained by the core developers as a group? ISTM that requiring a five-year commitment is just going to scare any contributors away - is that what we want?

What worries me most is that there seems to be a flow towards status quo on such things because status quo is the easiest to do. But in some cases, status quo is bad. Here we have a quite popular package in stdlib whose maintainer stopped maintaining it about two years ago. Another person stepped up and did some good work to bring the package up to date, fix bugs, and improve the test suite.

What happens now? Do we give up on touching it until Fredrik Lundh decides on a come-back or some person who is willing to commit 5 years is found? Or do we just keep maintaining it in the stdlib as we do with other modules, fixing bugs, tests, documentation and so on?

Eli



More information about the Python-Dev mailing list