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

[Tres Seaver]

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

Martijn Faassen wrote:

> You don't seem to get what I kept telling you over and over. I'm 
> therefore going to be more blunt.
> 
> I don't want to use zope.app packages in Grok. Grok wants to get rid of 
> zope.app packages. That's the very idea. We pushed this from the start. 
> I spent a huge amount of time to make this possible, just like everyone 
> else. But Grok isn't there yet. Neither are people who have to maintain 
> Zope 3 apps.

Sure, I hear you on that.

> But I have to use zope.app packages in Grok 1.1, because people need to 
> have a way to move off zope.app in a working system. It will be the 
> equivalent, I believe, of Zope 2.12, though the details are different. 
> We cannot ask users to switch their imports in Grok 1.0, as there, for 
> instance, zope.app.container is the only thing that exists. There is no 
> zope.container yet to switch your imports to.

And the versions.cfg maintained on the Grok trunk reflects that, right?
 I believe (without verification) that the list of zope.app packages
there is actually bigger than what Grok needs in and of itself at this
point.

> I am not asking you to help me maintain zope.app packages until the end 
> of time. I'm asking you to help me support backwards compatibility code 
> in zope.app for a while longer, until I and others have transitioned 
> away from those packages as well.

I'm not going to put proactive effort into maintaining those packages.
I will be glad to help other developers who run into such issues
diagnose them, and work out reasonable solutions for them, largely
through discussions on this list.

> If that code goes untested, it breaks. It already started breaking. 
> Jan-Wijbrand noticed test failures on zope.app.exception, just checking 
> it out from svn.zope.org. He didn't know a zope.publisher 3.12 was 
> released that created this breakage. He didn't even pin down the ZTK or 
> anything; it was just a checkout using the most recent releases. The 
> person who makes the change in the original package is likely able to 
> identify the cause for such breakage much more easily, and either warn 
> people about what to do, or make a quick fix himself.

Getting the buildbots to be nearly-always-green, and then whine when
anything goes red, is the only way I know of to ensure that such
breakage will be detected and reesolved quickly.  If I commit a change
to a non-zope.app package which causes a zope.app-dependent build to go
red, then I certainly expect to help the developers responsible for the
package set of the red build figure out out to fix it.  Unless they
bring the issue up, however, I'm gonna remain blissfully ignorant.

> So I'm using zope.app packages, and changes happen in the zope.* subset, 
> and zope.app packages are now breaking in SVN when buildouts are run.
> 
> Until recently Zope 2 used zope.app packages too, for backwards 
> compatibility reasons. If the situation had been reversed and Grok had 
> been off zope.app first, I don't think you would have been very happy if 
> suddenly these started breaking as they became unmaintained.

It used a subset of them which were *not* kept up to date with the ZTK.
 Please see the versions.cfg on the Zope 2.12 branch, and compare with
the ZTK trunk:

  http://svn.zope.org/Zope/branches/2.12/versions.cfg?rev=107345

  http://svn.zope.org/*checkout*/zopetoolkit/trunk/ztk.cfg?rev=107719

In effect, none of the "KGS" provided by the ZTK has been in use by
ZOpe2 for a long while:  one of the reasons I cheered Hanno's work was
that it finally got Zope2 to use the ZTK *directly*, rather than via a fork.

> Zope 2 is able to move off it more easily for a variety of reasons. Now 
> that you're done, but we aren't yet, I am hearing a loud "screw you, 
> we're done, we don't care about you anymore" from you.

Please don't put words in my mouth.

> That really pisses me off.
> 
> It's also just plain stupid if you only a little bit enlightened in your 
> self-interest and want the ZTK to succeed and people outside the Zope 2 
> community to use it. You're making that a lot harder. You're making my 
> lots life harder for short-term selfish reasons. And it makes me really 
> want to say "screw you too". But that would not be very enlightened.

I want the ZTK to succeed:  indeed, I have been working to position it
such that it might be useful even outside the bounds of the current Zope
community:  I think that moving the zope.app packages out of the ZTK
proper is the best possible thing we can do to move it towards success.

I don't see how I'm making your life harder here:  the zopeapp spinoff
you created gives folks who still need a managed set of those packages a
place to stand, while at the same time removing the burden of their
maintenance from the toolkit.  I never said that I wouldn't listen to
feedback from consumers of zopeapp who discovered a problem introduced
by a change in the ZTK.  In fact, I have said repeatedly that I want
real users report such problems, and would gladly help those developers
deal with them.  What I don't want to be held responsible for is
"hypothetical" breakage, and I'm certainly not going to be on the hook
to find such breakage myself in packages I don't use.


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

iEYEARECAAYFAktD1dkACgkQ+gerLs4ltQ4qcgCffy06cvMBFyCmr6yzDUkQ0Nek
OIkAoKZWs+8RXIw6VT0+MU06HEr2JJCV
=EYrr
-----END PGP SIGNATURE-----