[Zope-dev] removing zope.app from the ZTK
Martijn Faassen
faassen at startifact.com
Tue Dec 29 10:25:25 EST 2009
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.
Longer:
Here's my position on the role of zope.app within the ZTK and in our
community.
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
future.
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.
Regards,
Martijn
More information about the Zope-Dev
mailing list