-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: > Hanno Schlichting wrote: >> On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen <faas...@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 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 iEYEARECAAYFAks6hgwACgkQ+gerLs4ltQ5nOQCgz/0Am0QgWaRea6TSdM26DKIi 2XMAnRwv15iNsHkUxT7NUPDCl72ZU8Wj =z8oA -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
