Hi there,

Fastest summary:

* removing responsibility from the ZTK, yes, but not like this.

Quick summary:

* I agree we should dump most, perhaps all, of the code that is in 
zope.app.* from the ZTK. Most of these packages will likely eventually 
become unmaintained.

* We as a community have a responsibility to help the users of our 
software to help get to a world with a vastly smaller set of zope 
packages. We can't just ignore that responsibility.

* we can make a plan about when we will declare a lot of packages 
without support, after we've had some more experience with upgrading code.


Here's my position on the role of zope.app within the ZTK and in our 

We as the Zope community have been maintaining Zope 3 for years now. We 
have a lot of software that depends on it.

Earlier this year we decided to refocus our efforts on the ZTK, a 
leaner, meaner Zope 3 with a different focus, which has code that we 
really use, no UI, and with cleaner dependencies. As part of the 
dependency refactoring project, we've been factoring code out of 
zope.app.* packages that we do use and leaving the old zope.app.* 
packages behind.

A philosophical point: just because we have a dependency structure that 
*allows* us to remove zope.app.* from the dependency tree of the ZTK 
doesn't mean that only zope.* contains useful code that can be shared 
between our community. It's been a convenient shortcut to think in this 
way, but it isn't necessarily the case that we're done moving code out 
of zope.app.* into zope.*. I'll ignore this point below and assume that 
zope.app.* only contains old stuff that we don't want to maintain in the 

Recently the zope.app.* packages were entirely removed from the ZTK.

That we wish to remove zope.app.* from the ZTK at some point follows 
from the previous discussion, but as a community, I think we've 
certainly done this step too fast.

Since this is a *big* change and was done without sufficient discussion, 
I've reverted this change and added these packages back into the ZTK, in 
the "under review" section where they were before, and back to the 
versions list.

We need to maintain zope.app.* for the time being to help people off 
zope.app. We can't just drop the ball on this and offer no support.

The argument was made that the Zope 2 project has already taken care of 
this, and that other projects that use Zope 3 should also maintain their 
own backwards compatibility list separately and just work out their own 
upgrade stories.

This is exactly one of those jobs we should do centrally, and not 
delegate to subcommunities. That's neglecting our responsibility as a 
community and ignoring a *value* of our community.

In what form we should maintain the zope.app.* packages? I can see a 
construction where the main ZTK consists only of non-zope.app packages 
and that we, as ZTK developers, maintain a separate project for 
zope.app.*. This way we can continue to maintain and test this project 
as a community, and help people with a smooth upgrade.

We cannot just stop testing whether this works, or stop maintaining 
versions that work together. And that's what we did.

We can make a plan as to when we *will* officially drop support for 
these packages, or hand over maintainership to others, etc, and how we 
will help our community to get there. Our plan doesn't need to be 
perfect; we can expect some difficulty in this upgrade, but we should at 
least make a reasonable attempt.



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