Fwd: maintenance of the ElementTree / cElementTree packages in the Python standard library
---------- Forwarded message ----------
From: Fredrik Lundh
Hello Fredrik,
Recently a discussion came up on the python-dev mailing list regarding continued maintenance of the ElementTree & cElementTree packages which are part of the standard library, and which were originally contributed by you.
There currently exists an unclear situation with respect to the active maintainer(s) of these packages. On one hand, PEP 360 states that the packages are officially maintained in your repositories and all problems should be assigned to you and fixed upstream. On the other hand, it appears that there has already been made a considerable amount of work (e.g. http://codereview.appspot.com/207048/show) solely within the Python repositories, as well as the port to Python 3 which now lives in all 3.x branches. In other words, de-facto the package has been forked in the Python repository. Note that no changes (AFAIU) have been made to the ElementTree *API*, only to the implementations living in the stdlib.
I'd like to understand your point of view on this topic. There are currently 23 open issues on the package(s) in the Python tracker, and some additional plans are being made (such as 'import ElementTree' importing the C implementation by default, falling back on the Python implementation if that's unavailable). Is that alright with you that all such new fixes and developments are being made by Python code developers in the Python repositories directly, without waiting for your approval to submit them upstream?
Thanks in advance, Eli
On Fri, Feb 10, 2012 at 9:26 PM, Eli Bendersky
---------- Forwarded message ---------- From: Fredrik Lundh
Date: Fri, Feb 10, 2012 at 13:16 Subject: Re: maintenance of the ElementTree / cElementTree packages in the Python standard library To: Eli Bendersky Hi Eli, thanks for reaching out. I'll get back to you with a more "formal" reply later, but yeah, that sounds like a plan -- I have very limited time for core Python work these days anyway (as you guys have probably noticed :-).
I've updated PEP 360 accordingly (including a link back to the archived version of Fredrik's reply). Since ElementTree was the last Python module referenced from that PEP that hadn't been converted to python-dev maintenance, I flagged the PEP so it now appears in the Historical PEPs section rather than near the top of the PEP index. Technically the reference from there to the Expat XML parser being externally maintained is still valid, but the same could be said of various 3rd party libraries we ship with the Windows binaries. I also updated the headers on several old PEPs (mostly ones related specifically to the 3.0 process and the migration to Hg) to move them down into the Historical section, and fixed the PEP 0 generator so that Draft process PEPs (i.e. the PEP 407 proposal to change the release schedule) appear in the Open PEPs section along with all the other Draft PEPs. (At time of writing, the PEP pages hadn't regenerated to show the updated status of any of the PEPs I moved around, but I figure it will sort itself out eventually) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
A protagonist writes:
---------- Forwarded message ---------- From: Fredrik Lundh
As a not-directly-concerned third party who's been lurking, it seems to me like people are in way too much of a rush to "get things done". Sending direct mail, addressing the precise question[1] seems to have produced immediate results. (And yes, I've been on this list long enough to know that maintenance of ET/cET has been an issue for years. Nevertheless!) While actually maintaining the code is important, continuity in the community is important, too, and probably more so. In this case, continuity evidently will be achieved by a handoff rather than reactivation of Fredrik. It's a shame that this result had to be achieved by MvL putting his foot down. I'm glad he did. Footnotes: [1] Ie, not "when is this or that code issue going to be addressed", but "in view of your apparent schedule constraints, would it be OK to maintain the package in the stdlib with python-dev taking responsibility".
participants (3)
-
Eli Bendersky
-
Nick Coghlan
-
Stephen J. Turnbull