Fabio Tranchitella wrote:
> I've created a policy draft as well as an initial list of packages on
> a wiki page, which I hope will help us to collaborate on the list:
About the text on the wiki page:
> Addition of new packages
> A new package can be added to the ZTK in the following cases:
> * it has been factored out from existing ZTK packages; * it provides
> new fundamental blocks or features that change the way the
> toolkit-based libraries are used.
I like this set of guidelines.
> In order to add the package to the ZTK, all criteria defined by the
> policy must be met.
This line makes little sense to me. If I factor zope.foo out of
zope.bar, I don't provide a new fundamental building block or feature
that changes the way the libraries are used. zope.foo is still the in
> In case consensus can't be reached among Zope developers, the Zope
> Steering Group has a final word about the addition of the package.
I'll happily reverse this, as the Zope Toolkit Steering Group by
definition manages the Zope Toolkit. It always has the final word on
the addition of a package, consensus or not. Of course another task of
the steering group is to strive for consensus.
I'd just say:
"The Zope Toolkit Steering Group decides whether a package can be added
to the Zope Toolkit."
We can defer to the other document we already have about steering group
> Removal of packages
> A package can be removed from the ZTK if all the following conditions
> are true:
I think 'all conditions' is too strict.
> the package provides features that are not needed anymore because:
> * other packages provide compatible features;
compatible -> comparable?
> * there are better alternatives.
> * no package in the ZTK depends on it.
I have more difficulty with this, as I like to start with a more
inclusive list. Therefore, I want to remove packages that contain
functionality, such as the ZMI implementation, and things like 'code in
the ZODB' support that was experimental.
I think we can remove packages by the following *guidelines*:
* no other package depends on it.
* there are better alternatives.
* the feature the package defines is deprecated.
That's loose, as I don't define how features get deprecated. But that's
fine, as we're humans and we can make sensible decisions in specific cases.
> I've put into the list the packages that I'd consider part of the ZTK
> and that I use in my applications. I don't know anything about grok
> and I doN't have a list of ZTK libraries used by zope2 or repoze.
Okay, I really think we should end this discussion now; it's just not
I think the consensus within the steering group trends towards inclusion
(where Stephan wants to include way more than the others).
So, the list of packages in the ZTK was prepared by Christian Theune and
Any other list (such as the one on the wiki page you created) is not the
In addition, we are maintaining the documentation on the ZTK here:
A wiki might serve as a scratchpad for proposals and I'm fine with that,
but let's make sure that:
* the wiki page marks itself as a proposal clearly, otherwise it's a
decoy. It's not the real documentation.
* we integrate any such accepted proposals in the official documentation
Another way to propose documentation would be to create a branch of the
zopetoolkit documentation in SVN.
> I'd like to ask help from everybody who cares about the ZTK to
> enhance the list adding the packages that they use, their zope.org
> username in the list of the developers for the package they are
> willing to maintain and the framework which are consumers of the
I really think this is the wrong way to go about it. In order to produce
your list you'll need *everybody* to pay attention and do something. I
don't think such general cooperation of everybody is generally successful.
> IMHO, it is easier to get a real list if we start from an empty one
> and we add packages instead of starting from a huge list removing
-1, and I consider this a Zope Framework Steering Group decision.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -