Jens Vagelpohl wrote:
> How is that any different from people who won't use the ZTK because they
> don't want to deal with any zope.app* baggage?
We have a proposal for dealing with that now: To maintain two KGS', one
for ZTK and one for ZopeApp.
We can and should run tests for both, and ensure that ZopeApp depends on
the appropriate ZTK release. This way, if a ZTK package is changed in a
way that breaks ZopeApp, at least we'll know.
We have a number of people who have a stake in ZopeApp and are willing
to help maintain it. We also have a history of people maintaining
libraries caring about their consumers. You are the poster child for
that, I think, being immensely helpful with CMF releases for the
purposes of Plone. I don't see this being any different.
I think everyone agrees that:
- zope.app.* is not very interesting to anyone other than possibly a
subset being useful in Zope3/BlueBream/wahteveritgetscalled.
- We clearly had people using "some subset of Zope 3" for ages, long
before the ZTK concept existed.
- Ergo, we have a *lot* of zope.app.* imports in the wild.
- We tried to arrive at a common subset we could collectively maintain
to make all our lives easier and called that ZTK.
- We agree that ZTK should not have zope.app.* packages in it, or
indeed other "less useful" zope.* packages.
- We have a number of frameworks trying to move towards using the ZTK.
- Those frameworks are in various states of completion towards that goal.
- The shape of the ZTK itself is influenced by that process of
dependency untangling that allows frameworks to move towards adopting
it. Thus we have a two-way process of changes flowing between the ZTK
itself and the various consumers or would-be consumers. This was
evidenced when Hanno removed zope.app.* packages from the ZTK. That
helped the ZTK towards it end goal, but it also caused pain for people
whose frameworks are less advanced in that goal and may need zope.app.*
for a while longer.
- Waking up one morning to find your buildout going crazy and having
to backtrack in svn to find out what the KGS used to be and piecing it
together is not nice.
- There's benefit in having a tested set of zope.app.* packages and
testing that against the ZTK, so that when ZTK developers break a
zope.app.* package *that is currently used by someone*, they can at
least be aware of that.
- This situation may go away in the near-to-mid-term future when (a)
the major frameworks have managed to get a release out that uses the ZTK
proper without zope.app.* and/or (b) someone decides to actually love
some subset of zope.app.*. That "someone" is likely BlueBream or whatever.
So, in short:
- No-one wants zope.app.* in the ZTK.
- zope.app.* exists in the wild today, in real projects, for real
users, who we are going to ask to upgrade to some ZTK supported release
of their framework soon.
- Some people were disadvantaged when it disappeared over night and
need a bit more time/help to get there.
- Most/all people would like us to try to work together for mutual
The proposal to have a ZopeApp KGS with a buildbot and a dependency on
ZTK is perfectly reasonable. In the worst case scenario, those
self-styled ZTK maintainers who don't want to ever see zope.app.* again
will have a little bit of guilt because they broke other people's code.
In the best case, we'll work together to fix those breakages, or
identify that no-one cares about a particular zope.app.* and kill it
from ZopeApp forever.
Somehow, we all lost our cool at around the same time. Let's stop the
non-factual discussions and think about what people actually *need* to
get their jobs done, and find out who has interest and capacity to
And please, let's stop making this an "everyone vs. Martijn" debate,
because apart from a few lapses in style, he's actually making a lot of
sense and speaking for real people with real needs. I'll count myself as
one of them to shut up any debate about whether such people really exist.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -