[Zope-dev] shrinking the ZTK: a proposed solution

[Martin Aspeli]

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 
benefit.

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 
support that.

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book