Generally I believe that these rules if strictly applied wouldn't result 
in a usable ZTK. Hanno already mentions the testing dependencies, which 
we've barely started analyzing. Documentation in 'docs' would disqualify 
just about any package (and Reinout brings up a few objections).

A number of thoughts:

* even without radically pruning the ZTK particular subsets of the ZTK 
are becoming a lot more useful than when we started, due the dependency 
refactoring. This refactoring is ongoing.

* we need some stability for those apps that already are built on top of 
Zope 3. These will still be using zope.app* packages for some time. 
Right now we can test lots of breakages of zope.app* packages by using 
the ZTK compattests. If we removed them from the ZTK soon, we'd need an 
equivalent testing infrastructure for an expanded ZTK, and management 
policy will be harder.

I think we could translate these rules from "not be part of the ZTK" to 
goals for the ZTK packages:

- we should aim for ZTK packages to be used by Zope 3 apps, Zope 2 and 
Grok. The code in the ZTK should be *used*.

- ZTK packages should have narrative documentation. We should actively 
work to create such narrative documentation.

- We strive to remove zope.app.* packages from the ZTK or its 
dependencies. This can sometimes be done directly but can also be done 
by refactoring dependencies, factoring out useful code away from ZMI 
code, etc.

The implementation of these goals should be debated for individual 
packages. Of course this exposes us that the risk that nothing gets done 
and the ZTK remains as it is forever. A more aggressive set of rules 
might be seen as a way to force us to do something. I'm not sure whether 
that's a problem we need to solve: we do have people actively working on 
improving the ZTK, and this has been ongoing work for most of the year 
so far.  I'm also not sure whether the solution of aggressive removal 
would work: if we don't do anything, would we really start threatening 
people with aggressive removal?



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to