[Checkins] SVN: zope3docs/ Start pulling in some material and some references.
Christian Theune
ct at gocept.com
Mon Feb 2 11:29:33 EST 2009
Log message for revision 95987:
Start pulling in some material and some references.
Changed:
U zope3docs/Makefile
U zope3docs/source/conf.py
A zope3docs/source/process/bug-tracking.rst
A zope3docs/source/process/communication.rst
U zope3docs/source/process/index.rst
A zope3docs/source/process/maintaining-software.rst
A zope3docs/source/process/old-references.rst
A zope3docs/source/process/proposals.rst
A zope3docs/source/process/releasing-software.rst
A zope3docs/source/process/repository.rst
A zope3docs/source/process/tools.rst
-=-
Modified: zope3docs/Makefile
===================================================================
--- zope3docs/Makefile 2009-02-02 16:00:06 UTC (rev 95986)
+++ zope3docs/Makefile 2009-02-02 16:29:33 UTC (rev 95987)
@@ -11,8 +11,10 @@
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
-.PHONY: help clean html web pickle htmlhelp latex changes linkcheck
+.PHONY: help clean html web pickle htmlhelp latex changes linkcheck all
+all: html
+
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
Modified: zope3docs/source/conf.py
===================================================================
--- zope3docs/source/conf.py 2009-02-02 16:00:06 UTC (rev 95986)
+++ zope3docs/source/conf.py 2009-02-02 16:29:33 UTC (rev 95987)
@@ -42,16 +42,16 @@
# General information about the project.
project = u'Zope 3 Documentation'
-copyright = u'2009, Zope Developers'
+copyright = u'2009, Zope Foundation'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
-version = 'January 2009'
+version = '1'
# The full version, including alpha/beta/rc tags.
-release = 'January 2009'
+release = '1'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
Added: zope3docs/source/process/bug-tracking.rst
===================================================================
--- zope3docs/source/process/bug-tracking.rst (rev 0)
+++ zope3docs/source/process/bug-tracking.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,5 @@
+Bug tracking
+============
+
+Zope 3 bugs are tracked using Launchpad's bugtracker at
+https://bugs.launchpad.net/zope3.
Added: zope3docs/source/process/communication.rst
===================================================================
--- zope3docs/source/process/communication.rst (rev 0)
+++ zope3docs/source/process/communication.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,23 @@
+Communication
+=============
+
+Communication for the Zope 3 development itself happens both on IRC and
+in a mailinglist.
+
+IRC
+---
+
+We use #zope3-dev on the IRC network provided by `freenode.net
+<http://www.freenode.net>`_.
+
+
+Mailing list
+------------
+
+The official Zope 3 development mailing list is zope-dev at zope.org. You
+can subscribe to it by visiting http://mail.zope.org/mailman/listinfo/zope-dev.
+
+.. note::
+ In the earlier days of Zope 3 development we used to have a separate
+ mailing list for development on Zope 3 (zope3-dev at zope.org). This list was merged into
+ the general zope-dev at zope.org list a while ago.
Modified: zope3docs/source/process/index.rst
===================================================================
--- zope3docs/source/process/index.rst 2009-02-02 16:00:06 UTC (rev 95986)
+++ zope3docs/source/process/index.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -11,6 +11,13 @@
reference and to allow us build up new documents on their basis.
.. toctree::
+ :maxdepth: 1
- releasing-components
-
+ releasing-software
+ maintaining-software
+ repository
+ bug-tracking
+ communication
+ proposals
+ tools
+ old-references
Added: zope3docs/source/process/maintaining-software.rst
===================================================================
--- zope3docs/source/process/maintaining-software.rst (rev 0)
+++ zope3docs/source/process/maintaining-software.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,418 @@
+Maintaining software in the Zope software repository
+====================================================
+
+:Author: Philipp von Weitershausen <philipp at weitershausen.de>
+:Status: Draft
+
+
+.. contents::
+
+
+Introduction
+------------
+
+This guide outlines rules, recommendations and best practices for
+authors of software (mainly Python packages) that lives in the Zope
+software repository. It does not impose any new rules on existing
+software. It is mostly a written-down collection of rules,
+recommendations and best practices that have been maintained within
+the Zope community for some time now, some more than others.
+
+Therefore, the main purpose of this document is to document those
+existing practices for people who've joined the Zope project recently,
+and to serve as a canonical source for guidance when in doubt.
+
+
+Repository layout
+-----------------
+
+Here's an example of the directory naming conventions used in the Zope
+subversion repository at ``svn.zope.org``::
+
+ zope.component/
+ zope.component/branches/
+ zope.component/branches/3.4
+ zope.component/branches/philikon-100x-faster
+ ...
+ zope.component/tags/
+ zope.component/tags/3.4.0
+ zope.component/tags/3.4.0b1
+ zope.component/tags/3.4.1
+ ...
+ zope.component/trunk/
+ ...
+
+To summarize:
+
+* The top-level name of the directory is the project's name. This is
+ the name of the Python distribution ("egg"). If it contains just
+ one package, the dotted name of the package should be used for the
+ project name, e.g. ``zope.component``, ``z3c.form``. The same is
+ true for Zope 2 "products", e.g. ``Products.Five`` (note that not
+ all products adhere to this for legacy reasons, new projects should
+ use this convention, however).
+
+ It is recommended to put software in a namespace package to avoid
+ name clashes. Valid choices for namespace package names are:
+
+ * ``zope``, although this one is used by the Zope platform itself
+ and should only be used for new projects after approval from the
+ community.
+
+ * ``z3c`` (meaning "Zope 3 Community")
+
+ * your organization's name of an abbreviation of it, e.g. ``zc`` for
+ Zope Corporation, ``lovely`` for Lovely Systems, ``cc`` for
+ Creative Commons, etc.
+
+ Sometimes the project doesn't hold just one package but a number of
+ packages or not even software at all. In this case pick a
+ meaningful name that's unlikely to interfere with other names.
+
+* Below the top-level directory, we have the standard subversion
+ directory layout (``branches``, ``tags``, ``trunk``). Please
+ refrain from using custom naming schemes, such as calling the trunk
+ ``sandbox`` or something similar.
+
+* Release branches and release tags should be simple dotted numbers
+ stating the version that the branch or tag is for. Use ``3.4``, not
+ ``3.4.x`` or something else, for the release branch that's
+ responsible for ``3.4.0``, ``3.4.1``, etc.
+
+* Branches for doing temporary work (such as refactorings) should
+ begin with the login name of the primary author and then feature a
+ short and descriptive name of what they're about. For example,
+ ``philikon-100x-faster`` indicates that Philipp von Weitershausen is
+ working in making ``zope.component`` 100 times faster. You wish...
+
+ Temporary work branches should be short-lived and *removed* once
+ they're merged. Release branches and tags should never be removed.
+ Release tags shouldn't be committed to once the release has been
+ announced and distributed.
+
+
+Sandbox
+-------
+
+For private experiments that don't yet meet the maturity expected from
+software in the Zope repository (see `Package documentation and
+metadata`_ below), it is recommended to use the private sandbox,
+``Sandbox/<login name>/``. Software committed to this sandbox will
+still be subject to the Zope Contributor Agreement (as everything
+that's committed to the Zope repository).
+
+
+License
+-------
+
+Unless allowed otherwise, all software committed to the Zope
+repository is subject to the `Zope Public License (ZPL)`_. The
+documentation of the software should state so. In addition, each
+source code file should contain the following license header at the
+top::
+
+ ##############################################################################
+ #
+ # Copyright (c) 2007 Zope Corporation and Contributors.
+ # All Rights Reserved.
+ #
+ # This software is subject to the provisions of the Zope Public License,
+ # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
+ # THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
+ # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+ # FOR A PARTICULAR PURPOSE.
+ #
+ ##############################################################################
+
+The year and the current version of the ZPL are to be adjusted, of
+course.
+
+.. _Zope Public License (ZPL): http://www.zope.org/Resources/ZPL
+
+
+Coding style
+------------
+
+When starting new packages, one should adhere to the coding style
+suggested by `PEP 8`_. When modifying or enhancing existing software,
+the package's existing coding style should be used.
+
+.. _PEP 8: http://www.python.org/dev/peps/pep-0008/
+
+
+Automated tests
+---------------
+
+All software should be accompanied by automated tests. Packages that
+provide integrated components for the web should preferrably be
+accompanied by both unit tests and integration/functional tests. The
+definition of test cases should be done in ``tests`` packages or
+modules.
+
+Before checking modifications into the trunk or a release branch, all
+existing tests for the package must pass. Furthermore, when adding a
+feature, modifying the behaviour of a component or fixing a bug, a
+test exercising the change must be supplied as well. There would
+otherwise be no reproducible way of knowing whether the new code
+actually worked. In terms of automated tests, think "Untested code is
+broken code."
+
+Tests should be written in a fairly literate way with documentation of
+the test itself. That is to ensure that the intent of each test is
+clear and obvious to any other developer. One can use
+``unittest.TestCase`` as a test harness, or preferrably doctests_.
+
+We can differentiate two kinds of (doc)tests which should be separated
+from each other clearly:
+
+- **Executable documentation**
+
+ Since automated tests have to exercise every feature of the software
+ anyway, they might just as well serve as the software's
+ documentation. Doctests_ work especially well for this kind of
+ tests because they contain documentation text and test code at the
+ same time. Here's an example of executable documentation in doctest
+ format::
+
+ Defining interfaces
+ ===================
+
+ Interfaces are defined using Python class statements::
+
+ >>> import zope.interface
+ >>> class IFoo(zope.interface.Interface):
+ ... """Foo blah blah"""
+ ...
+ ... x = zope.interface.Attribute("""X blah blah""")
+ ...
+ ... def bar(q, r=None):
+ ... """bar blah blah"""
+
+ In the example above, we've created an interface, `IFoo`. We
+ subclassed `zope.interface.Interface`, which is an ancestor interface for
+ all interfaces, much as `object` is an ancestor of all new-style
+ classes [#create]_. The interface is not a class, it's an Interface,
+ an instance of `InterfaceClass`::
+
+ >>> type(IFoo)
+ <class 'zope.interface.interface.InterfaceClass'>
+
+ We can ask for the interface's documentation::
+
+ >>> IFoo.__doc__
+ 'Foo blah blah'
+
+ and its name::
+
+ >>> IFoo.__name__
+ 'IFoo'
+
+ As you can see, executable documentation is not just test code.
+ It's also a story which, just like all documentation, takes time and
+ effort to write. It is recommended to use first person plural
+ ("we") or second person ("you") in the story to involve the reader.
+ It also helps outlining use cases for the software, especially when
+ tests are written *before* the implementation ("test-driven
+ development").
+
+ Doctests should be valid reStructuredText and preferrably placed in
+ text files rather than in docstrings. The doctest files should be
+ named aptly so that developers can easily associate them with the
+ code in question, have the file extension ``.txt`` and are best
+ placed next to code in question.
+
+- **Other tests**, such as edge-case tests or bugfix tests. They too
+ need to be documented, but they usually have little value for
+ anybody seeking documentation on the software in question.
+
+.. _doctests: http://docs.python.org/lib/module-doctest.html
+
+
+Backward-compatibility
+----------------------
+
+As a rule of thumb, backwards-incompatible changes to stable, released
+code should be avoided. Examples of backwards-incompatible changes
+are
+
+* renaming packages, modules, classes, functions, etc. without
+ ensuring the old import paths still work,
+
+* changing a public interface, which also includes *adding* attributes
+ or methods (imagine people implemented this interface in their own
+ code, now all of a sudden their implementations don't comply with
+ the interface anymore)
+
+If you'd like to replace a certain component or package with another,
+better one, don't remove the original component or package, not even
+after a deprecation period. Instead, consider simply abandoning the
+original component or package. You should clearly document that, of
+course, possibly even by raising DeprecationWarnings. Then you
+provide the replacement under a separate name.
+
+For example, consider you would like to radically improve a package
+``mycorp.foo``. Instead of changing it in an incompatible way, you
+should just stop supporting it and create ``mycorp.newfoo`` (or
+whatever you'd like to name it).
+
+Consistency weighs higher than cleanliness.
+
+
+Package documentation and metadata
+----------------------------------
+
+It is recommended that all packages in the Zope repository are
+accompanied by at least the following minimum set of documentation and
+metadata (file names are relative to the package's distribution, in
+terms of a checkout they're relative to ``trunk`` or a release branch
+or tag):
+
+``README.txt``
+ This file should give an overview over what the package or project
+ is about. It is acceptable for this to be just a few paragraphs
+ or a full-fledged manual for the piece of software.
+
+ If ``README.txt`` contains a doctest that should be run as part of
+ the automated test suite, it usually needs to be placed inside the
+ Python package. In this case, a small ``README.txt`` at the top
+ level should point readers to it.
+
+ If the package has an associated mailinglist and a bugtracker, it
+ is a good idea to mention it here.
+
+ This file should contain valid reStructuredText_.
+
+ Here's an example for a short file containing only a few
+ paragraphs, but referring to more elaborate documentation
+ (doctests) inside the package::
+
+ Martian provides infrastructure for declarative configuration of
+ Python code. Martian is especially useful for the construction of
+ frameworks that need to provide a flexible plugin infrastructure.
+
+ Martian provides a framework that allows configuration to be expressed
+ in declarative Python code. These declarations can often be deduced
+ from the structure of the code itself. The idea is to make these
+ declarations so minimal and easy to read that even extensive
+ configuration does not overly burden the programmers working with the
+ code. Configuration actions are executed during a separate phase
+ ("grok time"), not at import time, which makes it easier to reason
+ about and easier to test.
+
+ For more information about using Martian, see:
+
+ src/martian/README.txt
+ src/martian/directive.txt
+ src/martian/scan.txt
+
+``CHANGES.txt``
+ This file contains the changelog. The changelog should keep track
+ of every new feature and every bugfix of all releases. When a
+ particular release has lots of changes, it may group them into
+ "Features" and "Bugfixes". The release date should be given for
+ each release in the ISO 8601 dash notation (YYYY-MM-DD). For
+ example::
+
+ 1.1 (unreleased)
+ ----------------
+
+ * ...
+
+ 1.0 (2007-01-24)
+ ----------------
+
+ * Fixed a memory leak.
+
+ * Improved documentation a lot.
+
+ 0.9 (2006-12-05)
+ ----------------
+
+ * Initial preview release.
+
+ This file should contain valid reStructuredText_.
+
+``setup.py``
+ Most Python software is distributed using distutils and
+ setuptools. By convention, the script to do the packaging should
+ be called ``setup.py``. The following example outlines the
+ *minimum* package metadata that it should contain::
+
+ from setuptools import setup, find_packages
+
+ long_description = (open('README.txt').read() +
+ '\n\n' +
+ open('CHANGES.txt').read())
+
+ setup(
+ name='z3c.awesomelib',
+ version='2.0.0dev',
+ url='http://pypi.python.org/pypi/z3c.awesomelib',
+ author='Philipp von Weitershausen',
+ author_email='philipp at weitershausen.de',
+ license='ZPL 2.1',
+ classifiers=['Environment :: Web Environment',
+ 'Intended Audience :: Developers',
+ 'License :: OSI Approved :: Zope Public License',
+ 'Programming Language :: Python',
+ 'Operating System :: OS Independent',
+ 'Topic :: Internet :: WWW/HTTP',
+ 'Framework :: Zope3',
+ ],
+ description="An awesome website implementation for Zope 3",
+ long_description=long_description,
+
+ packages=find_packages('src'),
+ package_dir={'': 'src'},
+ namespace_packages=['z3c'],
+ include_package_data=True,
+ install_requires=['setuptools', 'zope.interface, 'zope.component']
+ zip_safe=False,
+ )
+
+ To elaborate on this example:
+
+ * The blank line separates mostly informational metadata intended
+ for users from packaging metadata intended for setuptools.
+
+ * Many packages don't have their own "homepage" on zope.org. It
+ is often more convenient to use the `Python Package Index
+ (PyPI)`_ as a homepage for the package (via the ``url``
+ parameter) since PyPI renders ``long_description`` for the
+ package's main page and provides downloads.
+
+ It is not recommended to point ``url`` to the subversion
+ repository as it is misleading to both people and setuptools
+ (both will use it to find more information about the package and
+ the subversion repository isn't very helpful).
+
+ * The list of `Trove classifiers`_ (``classifiers`` parameter)
+ should be adjusted according to the specific package, of course.
+ Most of the software in the Zope repository is intended to be
+ used with the Zope 2 or Zope 3 framework (sometimes for both),
+ but not all (well-known exceptions are ``zope.interface`` or the
+ ``ZODB``).
+
+ * ``description`` should be a one-sentence description of the
+ package while ``long_description`` is best taken from the
+ ``README.txt`` file as demonstrated. You may also include the
+ changelog in ``long_description`` by concatenating ``README.txt
+ and ``CHANGES.txt``.
+
+.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+.. _Python Package Index (PyPI): http://pypi.python.org/pypi
+.. _Trove classifiers: http://pypi.python.org/pypi?%3Aaction=list_classifiers
+
+
+Missing subjects
+----------------
+
+This guide does not yet address, but probably should address
+
+* version numbering schemes (feature vs. bugfix releases),
+
+* which changes constitute new features (do new dependencies consist
+ of new features?),
+
+* how to deal with package dependencies.
Added: zope3docs/source/process/old-references.rst
===================================================================
--- zope3docs/source/process/old-references.rst (rev 0)
+++ zope3docs/source/process/old-references.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,14 @@
+Old reference material
+======================
+
+This is a collection of documents I found while putting together
+material for the Zope 3 process documentation. Most of those are so
+outdated or never made it very far that I didn't want to include them
+directly. They're here for giving an overview on what we might want to
+think of.
+
+- http://wiki.zope.org/DocumentationProcess
+- http://wiki.zope.org/DocsProcedures/FrontPage
+
+The original Zope 3 developer wiki contains a lot of information that
+still needs to be extracted. See http://wiki.zope.org/zope3/DeveloperInfo.
Added: zope3docs/source/process/proposals.rst
===================================================================
--- zope3docs/source/process/proposals.rst (rev 0)
+++ zope3docs/source/process/proposals.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,13 @@
+Proposals for new functionality
+===============================
+
+Proposals are a semi-formal way to write down our ideas for new
+functionality and larger changes to the code base. They are discussed
+and then get accepted (so somebody might be free to implement them) or
+denied. We keep them available for historical reference.
+
+The first place we gathered proposals was our wiki on the proposals
+page: http://wiki.zope.org/zope3/Proposals
+
+At some point we also started tracking their status in Launchpad usign
+the blueprint system: https://blueprints.launchpad.net/zope3/
Added: zope3docs/source/process/releasing-software.rst
===================================================================
--- zope3docs/source/process/releasing-software.rst (rev 0)
+++ zope3docs/source/process/releasing-software.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,109 @@
+Releasing software
+------------------
+
+When releasing software, the following steps should be taken:
+
+1. Make sure all automated tests of the package pass.
+
+2. Fill in the release date in ``CHANGES.txt``. Make sure the
+ changelog is complete.
+
+3. Make sure the package metadata in ``setup.py`` is up-to-date. You
+ can verify the information by re-generating the egg info::
+
+ python setup.py egg_info
+
+ and inspecting ``src/EGGNAME.egg-info/PKG-INFO``. You should also
+ make sure the that the long description renders as valid
+ reStructuredText. You can do this by using the ``rst2html.py``
+ utility from docutils_::
+
+ python setup.py --long-description | rst2html.py > test.html
+
+ If this will produce warnings or errors, PyPI will be unable to
+ render the long description nicely. It will treat it as plain text
+ instead.
+
+4. Create a release tag.
+
+5. Get a separate checkout of the release tag for creating the
+ distribution tarball and eggs. It is important that you don't do
+ this on the trunk or release branch to avoid
+
+ - forgetting to tag the release at all.
+
+ - forgetting to clean up the ``build`` directory that distutils and
+ setuptools create. Failure to do so may result in old artefacts
+ in eggs.
+
+ - forgetting to check in files that are needed by ``setup.py`` or
+ as package data. Setuptools will only include them in the
+ distribution if they are checked into subversion.
+
+ In the checkout of the tag perform the following steps:
+
+ a) Remove the "dev" marker from the version in ``setup.py``
+
+ b) Commit these changes. It's acceptable that these changes modify
+ the tag since they're purely related to release management.
+
+ c) Create a distribution and upload it to PyPI using the following
+ command::
+
+ python setup.py register sdist upload
+
+ If the package contains C extensions, you need to upload a
+ binary Windows egg as well::
+
+ python setup.py bdist_egg upload
+
+ This may require the help from someone with a Windows
+ installation and proper tools (Visual C).
+
+ Binary eggs for Linux or MacOSX should **never** be uploaded
+ because those platforms vary too much to be binary-compatible
+ with each other, due to varying UCS support, different libc
+ versions and linking models (framework / non-framework).
+
+6. Back on the trunk or the release branch, increase the version
+ number in ``setup.py`` to the *next* release while preserving the
+ ``dev`` marker. The convention is that the trunk or release branch
+ always points to the upcoming release, *not* the one that has been
+ released already. So if you've just released version 3.4.1, you
+ should change ``setup.py`` to read::
+
+ setup(
+ name='...',
+ version='3.4.2dev',
+ ...
+ )
+
+ In ``CHANGES.txt`` add a *new* section for the upcoming release.
+ The release date for that should say "unreleased" so that
+ committers recording their changes won't accidentally put their
+ entry in the section for an already released version. For
+ example::
+
+ 3.4.2 (unreleased)
+ ------------------
+
+ * ...
+
+ 3.4.1 (2007-01-24)
+ ------------------
+
+ * Fixed bug in the foo adapter.
+
+ * Added a bar utility for optimized kaboodling.
+
+ 3.4.0 (2006-09-13)
+ ------------------
+
+ Initial release as separate egg.
+
+**Important:** Once released to PyPI or any other public download
+location, a released egg may *never* be removed, even if it has proven
+to be a faulty release ("brown bag release"). In such a case it
+should simply be superseded immediately by a new, improved release.
+
+.. _docutils: http://docutils.sourceforge.net/
Added: zope3docs/source/process/repository.rst
===================================================================
--- zope3docs/source/process/repository.rst (rev 0)
+++ zope3docs/source/process/repository.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,20 @@
+Accessing the Zope 3 repository
+===============================
+
+The Zope 3 code is maintained via Subversion in the official Zope repository at
+svn://svn.zope.org/repos/main.
+
+Code browsing
+-------------
+
+The official code browser is reachable at http://svn.zope.org.
+
+An additional browser using `Trac` is available at
+http://zope3.pov.lt/trac/.
+
+Access rules
+------------
+
+There is a wiki which contains the guidelines for how to work with the
+repository including an introduction for new committers:
+http://www.zope.org/DevHome/Subversion/FrontPage
Added: zope3docs/source/process/tools.rst
===================================================================
--- zope3docs/source/process/tools.rst (rev 0)
+++ zope3docs/source/process/tools.rst 2009-02-02 16:29:33 UTC (rev 95987)
@@ -0,0 +1,11 @@
+Tools
+=====
+
+http://zope3.pov.lt/buildbot/
+ a buildbot run by POV that monitors the KGS for Zope 3.4
+
+http://buildbot.zope.org/
+ used to run a buildbot for various Zope projects but has been
+ retired.
+
+
More information about the Checkins
mailing list