-----BEGIN PGP SIGNED MESSAGE-----
Martijn Faassen wrote:
> Hi there,
> So here's my proposed solution for the ZTK shrinking issue:
> The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since
> Zope 2 forked the ZTK in response and continued to make changes to their
> fork, I've tried to keep it in sync with the Zope 2 fork.
> I've created a new 'zopeapp' package that expands the ZTK with zope.app.
> packages in my sandbox. This extracts that information from the ZTK.
> Hopefully after we get some feedback from other steering group members
> (very silent indeed in the holiday period when all this happened) we can
> make these two projects the official one: a ZTK project and a zopeapp
> A few things I ask the ZTK maintainers:
> I ask the ZTK maintainers to have the same concern for the zope.app
> packages as for any other user of the ZTK: work to support zopeapp's
> compatibility with the ZTK. If the zopeapp maintainers have issues,
> listen to them seriously. I think everybody can agree that this is
> within the ZTK mandate for the time being, as zopeapp clearly exists and
> is being used by a significant amount of people. (I'd like to work to
> retire it by making it used by far less people)
You're kidding, right? Different frameworks / pacakges use sets of
packages which intersect with the one you just invented and labeled
'zopeapp', but *nobody* is using that labeled set: it didn't even exist
a hundred hours ago. One thing that the consumers of zope.app.*
packages can do first is to contribute lists the specific sets (and
pinned versions) they depend on: without such information, nobody can
work to ensure that zopeapp is useful to those consumers. Yes, I'm
thinking specifically of Grok here, for one: I don't think
> I also strongly encourage the ZTK maintainers to consider the situation
> of backwards compatibility seriously. Help people transition from their
> code now to the ZTK. Helping everybody migrate to the ZTK smoothly
> increases the value of the ZTK itself.
People need to step up and ask for such help before it is even feasible
to consider helping them.
> Obviously I cannot *force* ZTK
> maintainers to worry about this. Instead I'm appealing to your
> self-interest. And of course the transition burden is shared and should
> not fall solely or even predominantly on the ZTK maintainers.
My self-interest? Not really: you are appealing to my altruism, in the
fact that I care about the *broader* Zope community (broader than Zope2,
Grok, Plone, or whatever. Neither of my chosen platforms (Zope2, bfg)
rely any longer on any of thsoe pacakages at all, which makes my direct
interest in them exactly zero.
Again, once real users with non-hypothetical needs speak up, I know that
the Zope developer community will help them, as it has alwasy done in
> I also think we as ZTK maintainers should better consider the concerns
> of other users of the ZTK. In this case, Zope 2 had less of a concern
> for zope.app than Grok or Zope 3. I didn't even understand this until
> the debate was further along. The concerns of others should be
> considered as well instead of simply rejected. We usually can find ways
> to balance the concerns of everybody. To that end concerns (or lack
> thereof) should be clearly communicated and be listened to.
For the ZTK to have any usefulness apart from "mere aggregation", it
needs to have a "crisp" identity. Anything which gets pulled into it
without specific, concrete need muddies that identity, and reduces the
value. Pushing to keep the set as small as possible is intended to
raise the quality and usefulness of the set for *all* its users:
excluding packages can actually help users of the ZTK who also use the
excluded packages, precisely because it makes clear the costs of using
the excluded pacakges (helping maintain them, for one).
Should the zopeapp set get users (e.g., Baiju's BlueBream takes off, or
if another Z3-based app ports to using it), that will make supporting
zopeapp's needs a reasonable request, simliar to supporting Plone via
Zope2. Until people organize such a community of interest around the
zopeapp set (or some other grouping), we don't have non-hypothetical
reasons to consider it viable.
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -