[Python-Dev] folding cElementTree behind ElementTree in 3.3

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