[Zope-dev] removing zope.app from the ZTK

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hanno Schlichting wrote:
>> On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen <faassen at startifact.com> wrote:
>>> And let's please not turn this around: I'm not putting anything *in*.
>>> Something was *removed*. Let's remove it responsibly. Not just disclaim
>>> responsibility and drop it all.
>> So far I defined the ZTK based on what we wrote on
>> http://docs.zope.org/zopetoolkit/about/coreextra.html.
>>
>> I never considered those zope.app packages to be part of the ZTK. For
>> me that was only a technical implementation detail on how to actually
>> get to something that fullfils those criteria about core packages.
> 
> That document should've helped clue you in about this too:
> 
> "The Zope Toolkit Steering Group is the final arbiter of which libraries 
> are in Zope Toolkit or not."
> 
> The idea was not to have unilateral decisions about this but to have 
> some discussion first. I think dropping lots of libraries counts as 
> something we need to talk about before it happens.
> 
> Again, I'm fine with the *goal* of making the ZTK those packages, but we 
> can't just leave the rest behind.
> 
>> But it seems our understanding is different and you want the
>> responsibility of moving Zope 3 users over to the ZTK to be the
>> responsibility of the ZTK. I don't agree with that, but that's my
>> problem :)
> 
> The ZTK cannot be an excuse to just drop support for a large part of the 
> existing users of the ZTK. It's a *means* to do so.

What existing users does the ZTK have?  I count exactly *one* user, the
Zope2 trunk (until Hanno backed it out).  Everybody else is using some
set of packages with a more-or-less sizable intersection with the ZTK,
but with no explicity dependency on the ZTK manifest at all.

>> To be able to make more actual progress I moved Zope2 off the toolkit
>> for now and we'll continue on our own. If at some point the ZTK offers
>> a package set, that is actually anywhere close to what Zope2 uses, we
>> can consider using it again. From my Zope2/Plone perspective I'm just
>> not interested at all in any zope.app code anymore.
> 
> The irony is that almost nobody is, including myself.

That isn't ironic, because we were all fully aware of it:  it does make
your point absurd, however.

> But the situation is also that you as Zope 2 developers have a plan to 
> support users that do still depend on zope.app code. Why don't you throw 
> that plan into the wider group of people here?

Because it is not relevant?  Zope2 does *not* intend to provide
"convenience dependencies" for BBB purposes, nor does Zope2 have any
plans for testing the no-longer-included packages in conjunction with
those which are included:  apps / frameworks which want to move to Zope
2.13 will need to pull in those dependencies themselves, and do any
appropriate maintenance / testing of them.  If that strategy works for
the ZTK, then there is no reason to revert it to include zope.app.*.

< We have a shared problem of backwards compatibility, right?

Wrong.  The strategy used for Zope2 was to eradicate use of those
packages, and to ship 2.13 in a configuration which doesn't include them
in any fashion.  Zope2 apps or frameworks which need zope.app pacakges
must declare those dependencies explicitly, and assume the burden of
maintaining / pinning appropriate / compatible versions.

> Perhaps less for Zope 2 than for 
> other Zope Toolkit using systems, as you never used the UI or the 
> content types.

You keep asserting a "backward compatibility problem," but haven't
defended it with any evidence.  Be specific:  who is hurt by the removal
of packages from the ZTK?

- - You can't claim that Grok users are so hurt:  they have their own KGS,
  and have not yet made a committment to use the ZTK, where commitment
  means doing the work required to define their superset of packages as
  a delta to the ZTK. Instead, the Grok versions.cfg file contains a
  *copy* of some version of the ZTK, including a bunch of zope.app
  packages.  It isn't even clear which of the zope.app packages are
  genuinely needed by Grok, as opposed to being copied in wholesale.
  Grok's existing test infrastructure drives of that versions.cfg file,
  and is so insulated from any changes to the ZTK.

- - The Zope3 crowd has again gone mostly silent, but their KGS setup
  doesn't depend on the ZTK in anyway.  The big majority of the zope.app
  packages are *only* interesting to this group, and will likely only
  be maintained by this group.

- - Potential future users of the zope.app packages?  Removing them from
  the ZTK is actually beneficial to those users, because it signals
  their relatively narrow focus and usefulness, as well as removing any
  implied proomise that they are being actively maintained by the wider
  Zope communtiy.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at 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

iEYEARECAAYFAks6hgwACgkQ+gerLs4ltQ5nOQCgz/0Am0QgWaRea6TSdM26DKIi
2XMAnRwv15iNsHkUxT7NUPDCl72ZU8Wj
=z8oA
-----END PGP SIGNATURE-----