Martijn Faassen wrote:

Andrey Tatarinov wrote:

...

As I see getting trac or something similar on Codespeak.net is a long time task, I suggest to migrate lxml development to TracOS.org, it gives complete Trac installiation (which is Wiki, Bug-tracker and has Svn integration), I think that will boost development and what is more important - documenting.

Martjin?

This needs a bit of thought on my side. I'm pretty happy with codespeak overall, know various of the people involved, and while Trac would be nice to have and may indeed boost development, those factors weigh strongly in my mind. I'll have a chat with the codespeak people to ask their opinion on this.

Trac support has been on ours minds for some time now. The big show stopper was always that trac wouldn't do multiple projects within one instance. At least that's what kept Holger & Co. from using it. I've been playing for some time now with the thought of installing a few separate trac instances, one for the z3base, possibly one for lxml and other projects that would like to have it. I'll need to talk to Holger about it.

Concerning boosting documentation -- documentation files/doctests are not hard to write under the present system. I wrote one for the SAX support yesterday (now checked in). Of course it would be nice if I weren't the only one writing them. :)

Yup. I don't think you always need a wiki to have docs. All of the z3base web pages are generated from reST documents in the repository. That means that source distributions also have that same info for people to read locally. And, of course, doctests rule... Philipp

On Fri, 2005-11-18 at 17:59 +0100, Martijn Faassen wrote:

Concerning boosting documentation -- documentation files/doctests are not hard to write under the present system. I wrote one for the SAX support yesterday (now checked in). Of course it would be nice if I weren't the only one writing them. :)

No, I mean not only documentation of implemented code, which could be found in repository, but development documentation/info also. i.e. not so long ago discussed API changes. Or for example my proposal for getting rid of two implementations of xpath. Mailing list archives are good, but only for historical reason, while we need a place for aggregating current state of process. I hope lxml will eventually get such place.