Fredrik Lundh wrote: >>That's primarily for the author of the software to decide, at this >>point. Fredrik Lundh would have to offer it for contribution first. > > > I've already done that, as others have noted. Everything I release > under a Python-compatible license is available for bundling with the > python core.
I see a difference here, though, between "offer for contribution" and "make available for bundling". To my knowledge, you never said (until now) "I would like to incorporate ElementTree into the Python CVS repository, and thus have it become part of future Python releases". > But it's correct that I want the core library (the parts that lives in the > python development trunk) to get smaller; that doesn't necessarily mean > that a standard Python distribution should ship with a smaller library. I know you said this before; I could never understand what you mean by that. I would always assume that we only ship what is in the source repository (plus, for the specific case of Windows binaries, what is documented in PCbuild/readme.txt). So how can the trunk get smaller, yet the distribution larger? > - I check in an existing elementtree release in a separate location in > the svn.python.org source tree. e.g. > > svn.python.org/kits/elementtree-1.2.6-20050316 > > this will make it clear that this is external software, and it also > provides a reference point for tracking down local changes Ah, so you want what CVS calls a "vendor branch": code that is externally maintained, and imported from time to time. Clearly, "local" (i.e. python.org) changes are one primary issue, so we should agree on an update process - I would personally prefer one that allows for merging (in the "svn merge" sense). The other issue is, of course, the question whose job it is to actually perform the updates. Would you expect to do that yourself, or would you expect somebody else does that? I'm still troubled that you keep saying that sgmlop "was forked". I had not been PyXML maintainer long enough to remember the precise history of things, but it was certainly the case that you could have updated it all the time - you still have write permission to the PyXML repository. > - we decide what elementtree modules to include, and where to place > them, and copy them to the python trunk. > > (suggestion: either directly under xml, or under xml.etree) Would there be a reason not to include the entire elementtree package? Either xml.etree, or xml.tree would be fine with me, -0 for putting it directly into xml. > - I adapt the elementtree selftest so it runs under Python's test suite Good. > - I convert the pythondoc pages for the included modules to match the > library reference format (someone will have to help with the markup > here) Would you then start using the tex sources as your primary sources, or would this conversion need to be done every time the package is updated? > - when new stable releases appear upstream, add to kits and copy > relevant modules. update/tweak docs as necessary. The "tweak docs" part sounds somewhat worrying. Of course, you could run "svn diff" on the old and new version, to see what doc strings have changed or appeared - but that might be quite some work. > - delegate incoming bug reports / patches to the upstream maintainer. Would it be sufficient to set you as the "Assigned To" in the SF tracker? I don't see specific bug reporting instructions on the elementtree page. > and, optionally > > - sort out expat bundling issues, and include cElementTree as well > (using the same approach as above). Not sure what this would be; we probably can look at it again when we are done with the first part. > whaddya think? Overall, sounds like a good plan. Regards, Martin _______________________________________________ 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
